Problems with today's control messages and Web site changes
Adam H. Kerman
ba.broadcast.moderated, I don't see rone's note that it was reissued
with the correct header signature. It appears that the incorrectly
signed message was processed anyway, which isn't supposed to happen.
The date header in the archived message doesn't match either of the
two messages sent. Is the date changed when a newgroup message is
archived?
http://ennui.org/ba/ba.broadcast.moderated-charter.txt
This isn't the actual newgroup message, but the draft.
http://ennui.org/ba/control.ctl
This isn't the current entry in control.ctl, so you want to update it?
I see that the Web site has the new checkgroups
http://ennui.org/ba/checkgroups.txt
but I haven't seen it propagated. Was it sent out?
Julien ÉLIE
> Checking the archived newgroup message at ftp.isc.org for
> ba.broadcast.moderated, I don't see rone's note that it was reissued
> with the correct header signature.
ftp://ftp.isc.org/pub/usenet/control/ba/ba.broadcast.moderated.gz
contains the two newgroup messages sent.
> It appears that the incorrectly
> signed message was processed anyway, which isn't supposed to happen.
These two newgroup control articles were only archived, not processed
for action. Both of them have an invalid signature.
> The date header in the archived message doesn't match either of the
> two messages sent. Is the date changed when a newgroup message is
> archived?
The Date: header seems fine (it is different from the first From line).
> http://ennui.org/ba/control.ctl
>
> This isn't the current entry in control.ctl, so you want to update it?
Information currently used is:
http://usenet.trigofacile.com/hierarchies/index.py?see=BA
It looks as though:
* the administrative group should be changed (ba.news.config -> ba.config);
* the PGP key should be updated.
Is the previous PGP key lost?
--
Julien �LIE
� H�te-toi de bien vivre et songe que chaque jour
est � lui seul une vie. � (S�n�que)
Adam H. Kerman
>Hi Adam,
>>Checking the archived newgroup message at ftp.isc.org for
>>ba.broadcast.moderated, I don't see rone's note that it was reissued
>>with the correct header signature.
>ftp://ftp.isc.org/pub/usenet/control/ba/ba.broadcast.moderated.gz
>contains the two newgroup messages sent.
Heh. I swear, rone's wasn't there when I looked just before writing this!
>>It appears that the incorrectly signed message was processed anyway,
>>which isn't supposed to happen.
>These two newgroup control articles were only archived, not processed
>for action. Both of them have an invalid signature.
Oops. I wasn't thinking. The criteria for archiving messages are quite
relaxed.
>>The date header in the archived message doesn't match either of the
>>two messages sent. Is the date changed when a newgroup message is
>>archived?
>The Date: header seems fine (it is different from the first From line).
Hm. I compared the Date header in the messages as I received them and in
the archives; identical. Never mind.
>>http://ennui.org/ba/control.ctl
>>This isn't the current entry in control.ctl, so you want to update it?
>Information currently used is:
> http://usenet.trigofacile.com/hierarchies/index.py?see=BA
>It looks as though:
> * the administrative group should be changed (ba.news.config -> ba.config);
Good point. The actual control.ctl entry isn't up-to-date either.
ba.config was started in a reorganization 11 years ago in which the
ba.news.* groups were rmgrouped, according to the initial newgroup
message for ba.config.
Adam H. Kerman
>>>http://ennui.org/ba/control.ctl
Today is Day Nine of the alleged existence of ba.broadcast.moderated.
The issue with the bad keys hasn't been dealt with. The issue of the
erroneous control.ctl entry for the hierarchy hasn't been dealt with.
The key file on the Web site and sample control.ctl entry both continue
to refer to ba.news.config and not ba.config, the former defunct since
1998. Is naming the wrong newsgroup sufficient for the key to fail?
The Web site has a text file of the message that would have been in a
checkgroups but no checkgroups has been issued reflecting the change in
the recognized set of newsgroups. When I checked the archived, I
couldn't find that a checkgroups had been issued all year.
The propagation search reports ba.broadcast.moderated created on four
servers checked (I assume none implements key verification for this
hierarchy) versus 38 servers for ba.broadcast.
I've seen exactly one thread, a meta discussion among the moderators. My
followup to that thread was rejected for being an "administrative"
message, so even the moderators seem to be sweeping the problems under
the rug.
This group isn't created on any server implementing key verification for
this hierarchy.
Who is hierarchy administrator and why isn't he following this discussion?
Patty Winter
In article <h4q51h$ep2$1...@news.albasani.net>,
Adam H. Kerman <a...@chinet.com> wrote:
>
>The propagation search reports ba.broadcast.moderated created on four
>servers checked (I assume none implements key verification for this
>hierarchy) versus 38 servers for ba.broadcast.
>
>I've seen exactly one thread, a meta discussion among the moderators.
No, it wasn't. I am a moderator and, at someone else's suggesation,
made one posting to see whether it would correctly be sent to the
moderation software instead of being posted directly to the group.
Perhaps I should not have subsequently approved its posting to the
group, and I apologize if I should not have conducted that experiment.
As you saw, I tried to limit the distribution of my message to that
server, but as I suspected would happen, that no longer works.
The two subsequent postings were from people on the same newserver
who were simply greeting the arrival of the group. They are not
moderatores, and there was no meta discussion (one posting said
"<waves>" and the other said "<pots up>"; hardly a "discussion"
of any sort), and I made no further postings. I don't plan to make
any more until the group has wider distribution.
>My followup to that thread was rejected for being an "administrative"
>message
Your posting was indeed administrative in nature and thus properly
directed to the moderators, not to the group, as is standard procedure
with moderated Usenet groups. We are still available at the stated
contact address.
Patty
Russ Allbery
> Today is Day Nine of the alleged existence of ba.broadcast.moderated.
> The issue with the bad keys hasn't been dealt with. The issue of the
> erroneous control.ctl entry for the hierarchy hasn't been dealt with.
> The key file on the Web site and sample control.ctl entry both continue
> to refer to ba.news.config and not ba.config, the former defunct since
> 1998. Is naming the wrong newsgroup sufficient for the key to fail?
Yes.
None of the rest of it has gotten dealt with since I have to do something
about it, I have friends here from out of town who can only visit once a
year (the only reason why I'm replying to this is because I was checking
Usenet briefly before a scheduled day of doing things with them, waiting
for them to show up), and I have basically no time to work on this during
this week. I was hoping to get it done last week inbetween traveling for
a conference, which failed when I got sick on the way back from the
conference and spent a couple of days groggy on antihistamines.
> The Web site has a text file of the message that would have been in a
> checkgroups but no checkgroups has been issued reflecting the change in
> the recognized set of newsgroups. When I checked the archived, I
> couldn't find that a checkgroups had been issued all year.
The hierarchy hadn't previously changed in eons, and I don't think it
makes sense for rone to issue a checkgroups until the key stuff is sorted
out.
> Who is hierarchy administrator and why isn't he following this
> discussion?
rone is well aware of what's going on and has already been in contact with
me. But he can't really do anything about it until I get a chance to
untangle the configuration and the key on isc.org.
The problem is that the key ID on the key we're distributing doesn't match
the configuration in control.ctl, so in order to honor the newgroup,
people are going to have to change one or the other. It sucks. Neither
he nor I caught that; it's been broken for years, and there just haven't
been any changes to the hierarchy.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Adam H. Kerman
>>The propagation search reports ba.broadcast.moderated created on four
>>servers checked (I assume none implements key verification for this
>>hierarchy) versus 38 servers for ba.broadcast.
>>I've seen exactly one thread, a meta discussion among the moderators.
>No, it wasn't. I am a moderator and, at someone else's suggesation,
>made one posting to see whether it would correctly be sent to the
>moderation software instead of being posted directly to the group.
>Perhaps I should not have subsequently approved its posting to the
>group, and I apologize if I should not have conducted that experiment.
Why didn't you post an actual on topic message, or an introductory
message to the group, as a test message?
>As you saw, I tried to limit the distribution of my message to that
>server, but as I suspected would happen, that no longer works.
I have no idea how you tried to limit distribution. Did you add an
actual Distribution header? I just don't see how the concept applies
when the gateway is in another city.
>The two subsequent postings were from people on the same newserver
>who were simply greeting the arrival of the group. They are not
>moderatores, and there was no meta discussion (one posting said
>"<waves>" and the other said "<pots up>"; hardly a "discussion"
>of any sort), and I made no further postings. I don't plan to make
>any more until the group has wider distribution.
So what's going on with that, the actual important topic of this thread?
You can't answer any of my concerns, only the hierarchy administrator
can, strangely absent from Usenet.
Who is it, anyway?
>>My followup to that thread was rejected for being an "administrative"
>>message
>Your posting was indeed administrative in nature and thus properly
>directed to the moderators, not to the group, as is standard procedure
>with moderated Usenet groups. We are still available at the stated
>contact address.
"The group is not propagating due to technical issues not being
addressed" isn't an issue of limited interest to administrators, but
important for all those who would be interested in reading the group
might wish to know. Obviously, that field of interest was limited to
users of three servers known to have created the group, but still.
I appreciate being treated in a heavy handed manner and thus receiving
the dubious distinction of being the first poster whose message wasn't
approved. The proponents claimed the moderated group was necessary for
other reasons that, er, too many "administrative" messages posted to
ba.broadcast. Way to play into behavioral roles anticipated by the
targets of moderation.
I don't care about the topic of discussion and wouldn't be a regular. My
interest was limited to the propagation issue not getting resolved.
Adam H. Kerman
Thanks to Julien for catching it.
Adam H. Kerman
>So what's going on with that, the actual important topic of this thread?
>You can't answer any of my concerns, only the hierarchy administrator
>can, strangely absent from Usenet.
>Who is it, anyway?
Never mind. Russ answered for rone.
Adam H. Kerman
administration of ba.* when the initial newgroup message for
ba.broadcast.moderated and incorrect "correction" booster were issued.
The situation has not been resolved and no one has even bothered to tell
us what is preventing the situation from being resolved.
This is a problem of extremely long standing, going back to the 1998
reorganization of ba.* 's configging newsgroups. The key continues to be
issued as if ba.news.config hadn't been rmgrouped in 1998, along with
the rest of ba.news.* groups. The current configging group is ba.config.
The entries for ba.* in control.ctl and as noted on the Web site in
http://ennui.org/ba/control.ctl, again because of this reorganization,
are not correct.
In the least important problem,
http://ennui.org/ba/ba.broadcast.moderated-charter.txt still isn't the
initial newgroup message, but a draft, so it's not controlling.
If this isn't resolved in the next few weeks and I'm so inclined, I'm
sure I'll mention this all again.
rone
Russ and i are still trying to sort this out. I attempted to send out
some more newgroups today but they failed to verify; my PGP keyring is
a bit of a hash, so i am trying to clean it up and redo it. I regret
and apologize for the mess.
rone
--
"The priest jabbered incomprehensibly on the distinctive nature of Christian
actions, as opposed to Jewish and Muslim actions, in the world. Not one word
about Mary. No connection to the readings. I am getting tired of this man,
and I think his liturgy is suspect." -- Richard Allan Baruz
Adam H. Kerman
>Russ and i are still trying to sort this out. I attempted to send out
>some more newgroups today but they failed to verify; my PGP keyring is
>a bit of a hash, so i am trying to clean it up and redo it. I regret
>and apologize for the mess.
Thank you kindly for the update.
Adam H. Kerman
>>It has now been three weeks. I noted the problems of hierarchy
>>administration of ba.* when the initial newgroup message for
>>ba.broadcast.moderated and incorrect "correction" booster were issued.
>>The situation has not been resolved and no one has even bothered to tell
>>us what is preventing the situation from being resolved.
>>This is a problem of extremely long standing, going back to the 1998
>>reorganization of ba.* 's configging newsgroups. The key continues to be
>>issued as if ba.news.config hadn't been rmgrouped in 1998, along with
>>the rest of ba.news.* groups. The current configging group is ba.config.
>>The entries for ba.* in control.ctl and as noted on the Web site in
>>http://ennui.org/ba/control.ctl, again because of this reorganization,
>>are not correct.
>>In the least important problem,
>>http://ennui.org/ba/ba.broadcast.moderated-charter.txt still isn't the
>>initial newgroup message, but a draft, so it's not controlling.
>>If this isn't resolved in the next few weeks and I'm so inclined, I'm
>>sure I'll mention this all again.
>Russ and i are still trying to sort this out. I attempted to send out
>some more newgroups today but they failed to verify; my PGP keyring is
>a bit of a hash, so i am trying to clean it up and redo it. I regret
>and apologize for the mess.
Did I misunderstand what Russ stated earlier?
The control.ctl entry and the public key on your Web site continue to
refer to the long defunct newsgroup ba.news.config. Isn't correcting all
that a necessary prerequisite to getting the key to work?
You sent more booster newgroup messages.
Russ Allbery
> Did I misunderstand what Russ stated earlier?
>
> The control.ctl entry and the public key on your Web site continue to
> refer to the long defunct newsgroup ba.news.config. Isn't correcting all
> that a necessary prerequisite to getting the key to work?
Given that nothing that verifies Usenet control messages does so on the
basis of the contents of a web site, no, it's not.
Step one is getting a combination of PGP key and control.ctl entry that
generates a signed control message which then verifies for someone other
than rone. Once we figure out which key and control.ctl entry accomplish
that, then we can document it, on that web site and elsewhere.
The problem is, there are two different keys, and those keys have multiple
different user IDs depending on which copy of the key you have because a
change of user ID to match the name of the newsgroup was incompletely
propagated. It looked like the 632E03A9 key with a user ID of
ba.news.config was the path of least resistance, but I may have been
wrong. (The correspondence between a user ID and an actual newsgroup is
unnecessary as long as all the configuration lines up.) However, I can
certainly change the ftp.isc.org configuration to use something different
instead.
It would be nice if, once we get this sorted out, we can tell people to
update only *one* thing, either the PGP keyring or the control.ctl file,
and not ask them to have to update both of them. We might have marginally
more success at getting this untangled. Maybe it would be better to go
with the F0BD2595 key and change control.ctl to expect ba.config. That
is more consistent with the current newsgroup names, even though that
doesn't matter from a technical perspective.
Adam H. Kerman
>>Did I misunderstand what Russ stated earlier?
>>The control.ctl entry and the public key on your Web site continue to
>>refer to the long defunct newsgroup ba.news.config. Isn't correcting all
>>that a necessary prerequisite to getting the key to work?
>Given that nothing that verifies Usenet control messages does so on the
>basis of the contents of a web site, no, it's not.
I wasn't assuming that verification uses another medium, but that
providing News administrators with correct configuration information is
a prerequisite.
>Step one is getting a combination of PGP key and control.ctl entry that
>generates a signed control message which then verifies for someone other
>than rone. Once we figure out which key and control.ctl entry accomplish
>that, then we can document it, on that web site and elsewhere.
>The problem is, there are two different keys, and those keys have multiple
>different user IDs depending on which copy of the key you have because a
>change of user ID to match the name of the newsgroup was incompletely
>propagated. It looked like the 632E03A9 key with a user ID of
>ba.news.config was the path of least resistance, but I may have been
>wrong. (The correspondence between a user ID and an actual newsgroup is
>unnecessary as long as all the configuration lines up.) However, I can
>certainly change the ftp.isc.org configuration to use something different
>instead.
I didn't realize the newsgroup name was being used as the user, so
yeah, I suppose the user could be anything at all. But if you're
gonna use a newsgroup name as the user, using the name of a newsgroup
that hierarchy administrator hasn't recognized for 11 years just seems
to be asking for trouble.
>It would be nice if, once we get this sorted out, we can tell people to
>update only *one* thing, either the PGP keyring or the control.ctl file,
>and not ask them to have to update both of them. We might have marginally
>more success at getting this untangled.
Thinking about this for a moment, I suspect that not having the keyring
in control.ctl is not any kind of stumbling block for a News
administrator to implement this verification method. As implementation
isn't a prerequisite for running a News server, and as there are real
advantages to having separate files, please don't include the keyring in
control.ctl. control.ctl is reasonably human readable. As most of it is
documentation, it's meant to be human readable. The keyring just doesn't
belong there.
Here's an example of the advantage of keeping control.ctl as human readable
as possible. I subscribe to a number of servers. When I realized
something was wrong with the newgroup message, I looked at control.ctl,
found the reference to the hierarchy's Web site, found a Web page in
checkgroups format, and requested that one of my servers process the
checkgroups manually to make changes (which also solved the 11 year old
ba.news.* reorganization locally).
It seems to me that following newgroup messages and checkgroups as they
come in and then processing them manually for hierarchies whose set of
recognized newsgroups don't change for more than a decade is a perfectly
reasonable way to administer a News server. It may not even be desirable
to process changes in regional hierarchies automatically. Changes are
infrequent and unexpected and something a News administrator might like
to eyeball first. Keeping control.ctl more human readable makes it easier
to handle changes manually.
>Maybe it would be better to go with the F0BD2595 key and change
>control.ctl to expect ba.config. That is more consistent with the
>current newsgroup names, even though that doesn't matter from a technical
>perspective.
Which key is more practical to use is a question for someone like Julien
or a working News administrator, not I.
Bob Vaughan
Could I get a progress report? 3 more weeks have elapsed, and we still don't
have the group at Stanford..
--
-- Welcome My Son, Welcome To The Machine --
Bob Vaughan | techie @ tantivy.net |
| P.O. Box 19792, Stanford, Ca 94309 |
-- I am Me, I am only Me, And no one else is Me, What could be simpler? --
Steve Bonine
> Could I get a progress report? 3 more weeks have elapsed, and we still don't
> have the group at Stanford..
Have you requested that the group be added?
Many sites these days don't automatically add newsgroups, even based on
a correctly-signed control message, and instead wait for a user to
request the group.
Adam H. Kerman
>Adam H. Kerman <a...@chinet.com> wrote:
>>rone <^*&#$@ennui.org> wrote:
>>>Russ and i are still trying to sort this out. I attempted to send out
>>>some more newgroups today but they failed to verify; my PGP keyring is
>>>a bit of a hash, so i am trying to clean it up and redo it. I regret
>>>and apologize for the mess.
>>Thank you kindly for the update.
>Could I get a progress report? 3 more weeks have elapsed, and we still don't
>have the group at Stanford..
Glancing at http://ennui.org/ba/ I see all the same files requiring
updating I saw way back on July 21, when I first noticed this matter.
rone?
Adam H. Kerman
Whoosh
Adam H. Kerman
the two keys to use?
Adam H. Kerman
>It's been more than two months now. What decision was made on which of
>the two keys to use?
Four months!
rone
Thanks for the nudge, i've been sitting on this. I need to go over my
mail with Russ to revisit what we settled on.