What hierarchies are still active? From the point of view of
"checkgroups" messages, here are the results:
About 24 hierarchies have posted checkgroups messages during 2017.
Another 30 hierarchies had older, locatable checkgroups messages since
2012 OR had a web page with a checkgroups listing.
About 93 PGP keys exist for checkgrouped hierarchies.
A total of about 289 hierarchies have (or had) a checkgroups maintainer.
This means that about 10% of hierarchies are actively checkgrouping.
Another 10% has a checkgroups list available but haven't sent it recently.
This leaves 80% of checkgroupable hierarchies that are INACTIVE (i.e.
not being maintained).
Except for those who have already sent a checkgroups message during 2017 >PLEASE ISSUE A CHECKGROUPS MESSAGE in July 2017. A failure
to issue a checkgroups message could lead to a recommendation that the >hierarchy be marked inactive and subsequently removed from
the "control.ctl" file. Thank you for your cooperation.
D. Stussy <newsgroups+replies@kd6lvw.ampr.org> wrote:
Except for those who have already sent a checkgroups message during 2017 >>PLEASE ISSUE A CHECKGROUPS MESSAGE in July 2017. A failure
to issue a checkgroups message could lead to a recommendation that the >>hierarchy be marked inactive and subsequently removed from
the "control.ctl" file. Thank you for your cooperation.
Any number of hierarchies, especially regional hierarchies, have never
issued checkgroups and have never bothered with PGP signing. If anyone
played hierarchy administrator in the past, they may have moved away.
Unless there's a problem to be addressed, leave well enough alone.
If there's no reason to amend control.ctl, don't alter it.
About 24 hierarchies have posted checkgroups messages during 2017.
Another 30 hierarchies had older, locatable checkgroups messages since
2012 OR had a web page with a checkgroups listing.
About 93 PGP keys exist for checkgrouped hierarchies.
Recent versions of GnuPG reject unsafe keys
using MD5 algorithm hashes.
This is a problem which should be dealt with but I do not see a smooth transition.
Regenerating new keys for hierarchy maintainers and adding
them for news administrators are huge changes.
Julien schrieb:
Recent versions of GnuPG reject unsafe keys
using MD5 algorithm hashes.
This is a problem which should be dealt with but I do not see a smooth >>transition.
I fear one will have to deal with it by using older version of GnuPG
for that use case.
Regenerating new keys for hierarchy maintainers and adding
them for news administrators are huge changes.
Yes. And I don't see those changes as feasible in a dead, dying or at
least stale Usenet.
Thomas Hochstein <thh@inter.net> wrote:[...]
Julien schrieb:
Recent versions of GnuPG reject unsafe keys
using MD5 algorithm hashes.
This is a problem which should be dealt with but I do not see a smooth
transition.
I fear one will have to deal with it by using older version of GnuPG
for that use case.
Of all the problems, I see this one as being unimportant, and not just because D.Stussy raised it. There's no issue unless a legitimate proponent proposes a newsgroup in an administered hierarchy, following its rules
for proposing newsgroups.
At that point, if he can argue that the hierarchy
administrator has abandoned his duties, yank the key from future
control.ctl.
Please don't do anything unless there's an issue.
Adam H. Kerman schrieb:
Thomas Hochstein <thh@inter.net> wrote:
Julien schrieb:
Recent versions of GnuPG reject unsafe keys
using MD5 algorithm hashes.
This is a problem which should be dealt with but I do not see a smooth >>>>transition.
I fear one will have to deal with it by using older version of GnuPG
for that use case.
[...]
Of all the problems, I see this one as being unimportant, and not just >>because D.Stussy raised it. There's no issue unless a legitimate proponent >>proposes a newsgroup in an administered hierarchy, following its rules
for proposing newsgroups.
There _is_ an issue, re-occuring about monthly, as checkgroups are
signed, too.
At that point, if he can argue that the hierarchy
administrator has abandoned his duties, yank the key from future >>control.ctl.
I'm not sure I can follow your reasoning here.
Please don't do anything unless there's an issue.
The issue at hand are old hierarchy keys that will possibly be
rejected in future due to newer GnuPG versions.
Changing the hierarchy key is no easy feat as it requires cooperation
(and manual intervention) of (all) newsmasters carrying the hierarchy.
"D" == D Stussy <spam@spam.org> writes:
What's this mean to cn.*? I believe the administrator and
main server of cn.* is missing for awhile, so there is no
one post checkgroups, but there are still some active
groups. Dose this mean the whole cn.* will be removed?
"D" == D Stussy <spam@spam.org> writes:
D> What hierarchies are still active? From the point of
D> view of "checkgroups" messages, here are the results:
D> About 24 hierarchies have posted checkgroups messages
D> during 2017. Another 30 hierarchies had older,
D> locatable checkgroups messages since 2012 OR had a
D> web page with a checkgroups listing. About 93 PGP
D> keys exist for checkgrouped hierarchies.
D> A total of about 289 hierarchies have (or had) a
D> checkgroups maintainer.
D> This means that about 10% of hierarchies are actively
D> checkgrouping. Another 10% has a checkgroups list
D> available but haven't sent it recently.
D> This leaves 80% of checkgroupable hierarchies that
D> are INACTIVE (i.e. not being maintained).
D> Except for those who have already sent a checkgroups
D> message during 2017 PLEASE ISSUE A CHECKGROUPS
D> MESSAGE in July 2017. A failure to issue a
D> checkgroups message could lead to a recommendation
D> that the hierarchy be marked inactive and
D> subsequently removed from the "control.ctl" file.
D> Thank you for your cooperation.
Thomas Hochstein <thh@inter.net> wrote:
There _is_ an issue, re-occuring about monthly, as checkgroups are
signed, too.
Abandoned cron job left running are rather irritating.
I agreed with your suggestion about continuing to use an older version
of GnuPG. It's extra work, I suppose, but control.ctl could include a
note about which version the key was created with.
I disagree with the suggestion of just removing the keys.
The issue at hand are old hierarchy keys that will possibly be
rejected in future due to newer GnuPG versions.
Changing the hierarchy key is no easy feat as it requires cooperation
(and manual intervention) of (all) newsmasters carrying the hierarchy.
The only alternative, if the hierarchy administrator doesn't generate new keys with stronger encryption, is to declare the hierarchy unadministrated.
I'm saying don't do that. That the old key will fail isn't a reason to
do that.
Adam H. Kerman schrieb:
Thomas Hochstein <thh@inter.net> wrote:
There _is_ an issue, re-occuring about monthly, as checkgroups are >>>signed, too.
Abandoned cron job left running are rather irritating.
Manual signing doesn't solve the problem ...
I agreed with your suggestion about continuing to use an older version
of GnuPG. It's extra work, I suppose, but control.ctl could include a
note about which version the key was created with.
You'll have the same problem on the receiving end: newsservers with
newer versions of GnuPG can't cope with old keys.
I disagree with the suggestion of just removing the keys.
A transition period will be necessary in any case, yes.
The issue at hand are old hierarchy keys that will possibly be
rejected in future due to newer GnuPG versions.
Changing the hierarchy key is no easy feat as it requires cooperation >>>(and manual intervention) of (all) newsmasters carrying the hierarchy.
The only alternative, if the hierarchy administrator doesn't generate new >>keys with stronger encryption, is to declare the hierarchy unadministrated.
Changing hierarchy keys is no simple feat ...
I'm saying don't do that. That the old key will fail isn't a reason to
do that.
Yes, of course!
Thomas Hochstein <thh@inter.net> wrote:
Adam H. Kerman schrieb:
Abandoned cron job left running are rather irritating.Manual signing doesn't solve the problem ...
Now you're changing the topic.
If the hierarchy administrator is issuing
these manually, then the hierarchy is still being actively administered.
It's not abandoned.
He's reachable and might be encouraged to implement
a higher-security key.
I disagree with the suggestion of just removing the keys.A transition period will be necessary in any case, yes.
Transition? You've been talking about exactly the opposite, that News administrators are expected to implement the latest applications, only,
which won't support keys made in previous versions.
The problem you've been alluding to is that an older and newer version
of GnuPG cannot both be running on the same host. Right?
But my point all along has been that there's no problem to solve unless
and until a decent proponent known for discussing the topic proposes that a properly justified group be created. Old hierarchy administrator abandoned the hierarchy? Then a new one will just have to step forward. Otherwise
the topic can be discussed in the *.misc or *.general group and the list
of recognized newsgroups in that hierarchy will remain static.
Sorry, I think I didn't make clear enough that I was discussing the
point Julien brought up in his followup (as that is something
bothering me, too), but not the question of "active" hierarchies.
Hi Thomas,
Sorry, I think I didn't make clear enough that I was discussing the
point Julien brought up in his followup (as that is something
bothering me, too), but not the question of "active" hierarchies.
Here are a few ideas (of course not fully satisfying):
- encourage news admins to synchronize their newsgroups list with the >ftp.isc.org active file. With INN, actsync can be used. Other news
servers may provide a similar utility.
https://www.eyrie.org/~eagle/software/inn/docs/actsync.html
Admins will need updating their configuration for that way to work.
The control-archive program used by ftp.isc.org of course must be able
to correctly process control articles with old and recent PGP keys.
- provide some way for news servers to keep the PGP keys up-to-date.
For instance with INN, adding an /updatekey/ keyword in control.ctl to >specify the hierarchies for which to do that. A cron job would
periodically achieve that (against PGPKEYS in ftp.isc.org or for
instance ><http://usenet.trigofacile.com/hierarchies/index.py?see=DE&only=pgpkeys>).
Admins will need updating their news server for that way to work.
Isn't the synching typically done with one's upstream provider?
Adam H. Kerman schrieb:
Isn't the synching typically done with one's upstream provider?
Peers are peers and do not have an "upstream" ...
[...]- encourage news admins to synchronize their newsgroups list with the
ftp.isc.org active file. With INN, actsync can be used. Other news
servers may provide a similar utility.
https://www.eyrie.org/~eagle/software/inn/docs/actsync.html
This has come up any number of times over the years. The argument
against it is ftp.isc.org is a test News server used to illustrate to
the proponent or hierarchy administrator how the control message would
be processed. Hence, any number of newsgroups were created here that
may not meet any News administrator's criteria for creation locally.
But the bigger counterargument is that hierarchies exist for which checkgroups was never issued and for which newgroups and rmgroups were
issued inconsistently over the years, especially true of institutional and regional hierarchies. You have personal experience of this with respect
to the unadministered microsoft.public.* hierarchy.
ftp.isc.org as an example of how to set up a new News server is better
than nothing, but there are superior choices.
- provide some way for news servers to keep the PGP keys up-to-date.
For instance with INN, adding an /updatekey/ keyword in control.ctl to
specify the hierarchies for which to do that. A cron job would
periodically achieve that (against PGPKEYS in ftp.isc.org or for
instance
<http://usenet.trigofacile.com/hierarchies/index.py?see=DE&only=pgpkeys>).
Admins will need updating their news server for that way to work.
What would it take to use control.ctl to distribute keys, given that it's maintained on a regular basis?
Hi Adam,
- encourage news admins to synchronize their newsgroups list with the >>>ftp.isc.org active file. With INN, actsync can be used. Other news >>>servers may provide a similar utility.
https://www.eyrie.org/~eagle/software/inn/docs/actsync.html
[...]
This has come up any number of times over the years. The argument
against it is ftp.isc.org is a test News server used to illustrate to
the proponent or hierarchy administrator how the control message would
be processed. Hence, any number of newsgroups were created here that
may not meet any News administrator's criteria for creation locally.
But the bigger counterargument is that hierarchies exist for which >>checkgroups was never issued and for which newgroups and rmgroups were >>issued inconsistently over the years, especially true of institutional and >>regional hierarchies. You have personal experience of this with respect
to the unadministered microsoft.public.* hierarchy.
I understand the argument; yet, I do not see how news admins could
easily get the "common" list of newsgroups for such hierarchies. Using
the ftp.isc.org news server can serve, as there does not seem to exist
any better option.
If "reasonable" newsgroups should be added/deleted in these hierarchies, >people can ask for such a change.
ftp.isc.org as an example of how to set up a new News server is better
than nothing, but there are superior choices.
What are the superior choices?
- provide some way for news servers to keep the PGP keys up-to-date.
For instance with INN, adding an /updatekey/ keyword in control.ctl to >>>specify the hierarchies for which to do that. A cron job would >>>periodically achieve that (against PGPKEYS in ftp.isc.org or for
instance >>><http://usenet.trigofacile.com/hierarchies/index.py?see=DE&only=pgpkeys>).
Admins will need updating their news server for that way to work.
What would it take to use control.ctl to distribute keys, given that it's >>maintained on a regular basis?
There is also the PGPKEYS file similarly maintained on a regularly
basis, and made available through ftp.isc.org.
https://ftp.isc.org/pub/pgpcontrol/ . . .
I understand the argument; yet, I do not see how news admins could
easily get the "common" list of newsgroups for such hierarchies. Using
the ftp.isc.org news server can serve, as there does not seem to exist
any better option.
If an institutional hierarchy wasn't administered with control messages,
then anything in the sample active file at ftp.isc.org is arbitrary.
If "reasonable" newsgroups should be added/deleted in these hierarchies,
people can ask for such a change.
One can request a newsgroup be created from one's News administrator, yes. One cannot request that it appear in the active file at ftp.isc.org,
for that requires declaring one's self hierarchy administrator in order
to issue control messages.
The only reasonable way is to peer with the institution's own News server
and copy the groups it created.
Hi Adam,
I understand the argument; yet, I do not see how news admins could
easily get the "common" list of newsgroups for such hierarchies. Using >>>the ftp.isc.org news server can serve, as there does not seem to exist >>>any better option.
If an institutional hierarchy wasn't administered with control messages, >>then anything in the sample active file at ftp.isc.org is arbitrary.
If "reasonable" newsgroups should be added/deleted in these hierarchies, >>>people can ask for such a change.
One can request a newsgroup be created from one's News administrator, yes. >>One cannot request that it appear in the active file at ftp.isc.org,
for that requires declaring one's self hierarchy administrator in order
to issue control messages.
The only reasonable way is to peer with the institution's own News server >>and copy the groups it created.
I beg to differ as the control.ctl file has the notion of "syncable
server" to mention the news server name of the institution. I then
believe that the groups present in that institution server can be
declared in the active file at ftp.isc.org, if asked.
BTW, if Russ reads us, the msnews.microsoft.com news server has retired.
It can be removed from control.ctl. Maybe the microsoft.* hierarchy
should now be considered historic or at least unmanaged? (there are
still a few discussions in some newsgroups)
What's this mean to cn.*? I believe the administrator and
main server of cn.* is missing for awhile, so there is no
one post checkgroups, but there are still some active
groups. Dose this mean the whole cn.* will be removed?
"D" == D Stussy <spam@spam.org> writes:
D> What hierarchies are still active? From the point of
D> view of "checkgroups" messages, here are the results:
D> About 24 hierarchies have posted checkgroups messages
D> during 2017. Another 30 hierarchies had older,
D> locatable checkgroups messages since 2012 OR had a
D> web page with a checkgroups listing. About 93 PGP
D> keys exist for checkgrouped hierarchies.
D> A total of about 289 hierarchies have (or had) a
D> checkgroups maintainer.
D> This means that about 10% of hierarchies are actively
D> checkgrouping. Another 10% has a checkgroups list
D> available but haven't sent it recently.
I sent out a checkgroups in mid-2017, and another one just now.
I don't see that either has been archived, which makes me think it
hasn't propogated. How can I check?
I'd like to verify control messages are propogating as I'd like to send
one every six months or so, just as a sign of life.
On 06/21/2018 12:02 PM, RS Wood wrote:
I sent out a checkgroups in mid-2017, and another one just now.
I don't see that either has been archived, which makes me think it
hasn't propogated. How can I check?
I'm not sure how to check off the top of my head.
That being said, I did just receive checkgroups message.
Message-ID: <checkgroups-1529600885@stalin.dictatorshandbook.net>
Thanks Grant.
That seems to confirm the checkgroup messages are propogating.
I sent out a checkgroups in mid-2017, and another one just now. I don't see that either has been archived, which makes me think it hasn't propogated.
How can I check?
Regardless, the info in the control.ctl file is correct atConfiguration can also be seen here:
ftp.isc.org.
I'd like to verify control messages are propogating as I'd like to send one every six months or so, just as a sign of life.
Hi RS Wood,
I sent out a checkgroups in mid-2017, and another one just now. I don't see >>that either has been archived, which makes me think it hasn't propogated. >>How can I check?
You can check the logs of ftp.isc.org here:
https://ftp.isc.org/pub/usenet/CONFIG/LOGS/
You'll then see that the 2 checkgroups you sent on June 21st failed to
be processed (a line with the keyword "processed" should be present):
2018-06-21 17:00:03 [11306] ><checkgroups-1529599601@stalin.dictatorshandbook.net> archived checkgroups >2018-06-21 17:20:02 [12427] ><checkgroups-1529600885@stalin.dictatorshandbook.net> PGP: gpg:
Signature made Thu Jun 21 10:08:14 2018 PDT using RSA key ID 8361E3C3 >2018-06-21 17:20:02 [12427] ><checkgroups-1529600885@stalin.dictatorshandbook.net> PGP: gpgv exited
with status 2
2018-06-21 17:20:02 [12427] ><checkgroups-1529600885@stalin.dictatorshandbook.net> archived checkgroups
Regardless, the info in the control.ctl file is correct at
ftp.isc.org.
Configuration can also be seen here:
http://usenet.trigofacile.com/hierarchies/index.py?see=DICTATOR
I'd like to verify control messages are propogating as I'd like to send one >>every six months or so, just as a sign of life.
That's pretty good practise!
Julien <iulius@nom-de-mon-site.com.invalid> wrote:
Hi RS Wood,
You'll then see that the 2 checkgroups you sent on June 21st failed to
be processed (a line with the keyword "processed" should be present):
Because the key isn't in the keyring?
On 2018-07-02, Adam H. Kerman <ahk@chinet.com> wrote:
Julien <iulius@nom-de-mon-site.com.invalid> wrote:
Hi RS Wood,
You'll then see that the 2 checkgroups you sent on June 21st failed to
be processed (a line with the keyword "processed" should be present):
Because the key isn't in the keyring?
That's my question as well - is there something I should do, as >administrator? Is it possible the key wasn't updated when I had to rebuild >my server a few years ago?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 292 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 201:55:50 |
| Calls: | 6,617 |
| Calls today: | 1 |
| Files: | 12,168 |
| Messages: | 5,316,243 |