You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan Sperling <st...@apache.org> on 2021/02/10 15:35:50 UTC
Re: Returned post for announce@apache.org
Sebb, blocking our release announcements over trivialities like this
really is not a nice thing to do. Last time it happened in May 2020.
It was already discussed back then and raised with the announce@
moderation team.
The Subversion PMC came to the conclusion that our handling of
the KEYS files is adequate for our purposes:
https://svn.haxx.se/dev/archive-2020-05/0156.shtml
Please raise the issue on our dev@subversion.a.o list if it bothers you.
The moderation mechanism is supposed to prevent spam. Using it to enforce
release workflow policies amounts to misuse of your moderation privileges.
Regards,
Stefan
On Wed, Feb 10, 2021 at 03:20:41PM -0000, announce-owner@apache.org wrote:
>
> Hi! This is the ezmlm program. I'm managing the
> announce@apache.org mailing list.
>
> I'm working for my owner, who can be reached
> at announce-owner@apache.org.
>
> I'm sorry, your message (enclosed) was not accepted by the moderator.
> If the moderator has made any comments, they are shown below.
>
> >>>>> -------------------- >>>>>
> Sorry, but the announce cannot be accepted.
> The linked download page does not contain links for the version in the
> email.
>
> Also, the standard name for the KEYS file is KEYS - no prefix, no suffix.
> Please correct the download page, check it, and submit a corrected announce
> mail.
>
> Thanks,
> Sebb.
> <<<<< -------------------- <<<<<
>
> Date: Wed, 10 Feb 2021 14:37:00 +0100
> From: Stefan Sperling <st...@apache.org>
> To: announce@subversion.apache.org, users@subversion.apache.org,
> dev@subversion.apache.org, announce@apache.org
> Cc: security@apache.org, oss-security@lists.openwall.com,
> bugtraq@securityfocus.com
> Subject: [SECURITY][ANNOUNCE] Apache Subversion 1.10.7 released
> Message-ID: <YC...@byrne.stsp.name>
> Reply-To: users@subversion.apache.org
> Content-Type: text/plain; charset=utf-8
>
> I'm happy to announce the release of Apache Subversion 1.10.7.
> Please choose the mirror closest to you by visiting:
>
> https://subversion.apache.org/download.cgi#supported-releases
>
> This is a stable bugfix and security release of the Apache Subversion
> open source version control system.
>
> THIS RELEASE CONTAINS AN IMPORTANT SECURITY FIX:
>
> CVE-2020-17525
> "Remote unauthenticated denial-of-service in Subversion mod_authz_svn"
>
> The full security advisory for CVE-2020-17525 is available at:
> https://subversion.apache.org/security/CVE-2020-17525-advisory.txt
>
> A brief summary of this advisory follows:
>
> Subversion's mod_authz_svn module will crash if the server is using
> in-repository authz rules with the AuthzSVNReposRelativeAccessFile
> option and a client sends a request for a non-existing repository URL.
>
> This can lead to disruption for users of the service.
>
> We recommend all users to upgrade to the 1.10.7 or 1.14.1 release
> of the Subversion mod_dav_svn server.
>
> As a workaround, the use of in-repository authz rules files with
> the AuthzSVNReposRelativeAccessFile can be avoided by switching
> to an alternative configuration which fetches an authz rules file
> from the server's filesystem, rather than from an SVN repository.
>
> This issue was reported by Thomas Åkesson.
>
> SHA-512 checksums are available at:
>
> https://www.apache.org/dist/subversion/subversion-1.10.7.tar.bz2.sha512
> https://www.apache.org/dist/subversion/subversion-1.10.7.tar.gz.sha512
> https://www.apache.org/dist/subversion/subversion-1.10.7.zip.sha512
>
> PGP Signatures are available at:
>
> https://www.apache.org/dist/subversion/subversion-1.10.7.tar.bz2.asc
> https://www.apache.org/dist/subversion/subversion-1.10.7.tar.gz.asc
> https://www.apache.org/dist/subversion/subversion-1.10.7.zip.asc
>
> For this release, the following people have provided PGP signatures:
>
> Stefan Sperling [2048R/4F7DBAA99A59B973] with fingerprint:
> 8BC4 DAE0 C5A4 D65F 4044 0107 4F7D BAA9 9A59 B973
> Branko Čibej [4096R/1BCA6586A347943F] with fingerprint:
> BA3C 15B1 337C F0FB 222B D41A 1BCA 6586 A347 943F
> Johan Corveleyn [4096R/B59CE6D6010C8AAD] with fingerprint:
> 8AA2 C10E EAAD 44F9 6972 7AEA B59C E6D6 010C 8AAD
>
> These public keys are available at:
>
> https://www.apache.org/dist/subversion/subversion-1.10.7.KEYS
>
> Release notes for the 1.10.x release series may be found at:
>
> https://subversion.apache.org/docs/release-notes/1.10.html
>
> You can find the list of changes between 1.10.7 and earlier versions at:
>
> https://svn.apache.org/repos/asf/subversion/tags/1.10.7/CHANGES
>
> Questions, comments, and bug reports to users@subversion.apache.org.
>
> Thanks,
> - The Subversion Team
>
> --
> To unsubscribe, please see:
>
> https://subversion.apache.org/mailing-lists.html#unsubscribing
>
Re: Returned post for announce@apache.org
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Branko Čibej wrote on Thu, Feb 11, 2021 at 08:03:04 +0100:
> the purpose of moderation is [...] certainly not to anonymously enforce your
> conception of policy, [...]
For future reference, it wasn't entirely anonymous; the author's identity was
recorded in the headers:
Sender: sebb@gsuite.cloud.apache.org
Re: Returned post for announce@apache.org
Posted by Branko Čibej <br...@apache.org>.
On 11.02.2021 01:51, Private List Moderation wrote:
> On Wed, 10 Feb 2021 at 22:26, Erik Huelsmann <ehuels@gmail.com
> <ma...@gmail.com>> wrote:
>
> How can a link be more important than an announcement for a fix of an
> *unauthenticated* remote DoS ?
>
>
> When I checked the download page, there were no links for versions
> 1.10.7 or 1.14.1.
> i.e. the 2 announce mails were telling people to download versions
> that were not on the download page.
>
> As such, I felt I had to reject the announce email.
You know very well that the proper escalation path is to notify dev@, in
a separate mail, about the omission. Just like any other bug report.
As Stefan already said, the purpose of moderation is to prevent spam,
not to meddle in the PMC's business. And certainly not to anonymously
enforce your conception of policy, without discussion. Blocking the
announcement of a remote-DOS fix on a trivial technicality is way
outside a moderator's writ.
-- Brane
Re: Returned post for announce@apache.org
Posted by Private List Moderation <mo...@gsuite.cloud.apache.org>.
On Thu, 11 Feb 2021 at 12:17, Branko Čibej <br...@apache.org> wrote:
> On 11.02.2021 12:02, Private List Moderation wrote:
>
> On Thu, 11 Feb 2021 at 07:04, Stefan Sperling <st...@apache.org> wrote:
>
>> On Wed, Feb 10, 2021 at 11:03:39PM -0500, Nathan Hartman wrote:
>> > On Wed, Feb 10, 2021 at 7:51 PM Private List Moderation <
>> > mod-private@gsuite.cloud.apache.org> wrote:
>> > > When I checked the download page, there were no links for versions
>> 1.10.7
>> > > or 1.14.1.
>> > > i.e. the 2 announce mails were telling people to download versions
>> that
>> > > were not on the download page.
>> > >
>> > > As such, I felt I had to reject the announce email.
>> > >
>> > > It looks as though the page has since been updated.
>> > >
>> >
>> >
>> > That was a race condition.
>>
>> Worse, it's a chicken-and-egg problem which is documented here:
>>
>> http://subversion.apache.org/docs/community-guide/releasing.html#releasing-release
>> """
>> NOTE: We announce the release before updating the website since the
>> website update links to the release announcement sent to the announce@
>> mailing list.
>> """
>>
>>
> Which is worse for the end user?
> - a broken link to the release announcement
> - a missing link to the download artifact referenced by the official
> announcement
>
>
> You forgot:
> - a missing release announcement.
>
> I'm pretty sure users are capable of telling us about missing links, but
> not about missing announcements.
>
>
Of course.
But if I had sent an email to the dev list instead of rejecting the
announce, the mail would still have been missing.
-- Brane
>
>
Re: Returned post for announce@apache.org
Posted by Branko Čibej <br...@apache.org>.
On 11.02.2021 12:02, Private List Moderation wrote:
> On Thu, 11 Feb 2021 at 07:04, Stefan Sperling <stsp@apache.org
> <ma...@apache.org>> wrote:
>
> On Wed, Feb 10, 2021 at 11:03:39PM -0500, Nathan Hartman wrote:
> > On Wed, Feb 10, 2021 at 7:51 PM Private List Moderation <
> > mod-private@gsuite.cloud.apache.org
> <ma...@gsuite.cloud.apache.org>> wrote:
> > > When I checked the download page, there were no links for
> versions 1.10.7
> > > or 1.14.1.
> > > i.e. the 2 announce mails were telling people to download
> versions that
> > > were not on the download page.
> > >
> > > As such, I felt I had to reject the announce email.
> > >
> > > It looks as though the page has since been updated.
> > >
> >
> >
> > That was a race condition.
>
> Worse, it's a chicken-and-egg problem which is documented here:
> http://subversion.apache.org/docs/community-guide/releasing.html#releasing-release
> <http://subversion.apache.org/docs/community-guide/releasing.html#releasing-release>
> """
> NOTE: We announce the release before updating the website since the
> website update links to the release announcement sent to the announce@
> mailing list.
> """
>
>
> Which is worse for the end user?
> - a broken link to the release announcement
> - a missing link to the download artifact referenced by the official
> announcement
You forgot:
- a missing release announcement.
I'm pretty sure users are capable of telling us about missing links, but
not about missing announcements.
-- Brane
Re: Returned post for announce@apache.org
Posted by Nathan Hartman <ha...@gmail.com>.
On Sat, Feb 13, 2021 at 6:57 AM Private List Moderation
<mo...@gsuite.cloud.apache.org> wrote:
>
> On Thu, 11 Feb 2021 at 19:24, Nathan Hartman <ha...@gmail.com> wrote:
>>
>> On Thu, Feb 11, 2021 at 11:33 AM Daniel Sahlberg
>> <da...@gmail.com> wrote:
>> >
>> > *thread reply*
>> >
>> > I think everyone should take a deep breath and then we should re-start the conversation with the purpose of learning and improving because at the moment it seems that emotions are way to high.
>> >
>> > As I see it - and as usual, I'm new to the party so I don't have historical context:
>> >
>> > * Subversion release process dictate to announce first, update website later. There is a reason for it but we can improve on the process. I've raised this at dev@ and received positive feedback from stsp.
>> > * The RM an honest mistake and forgot to update the download page on the website. He has admitted and apologized. No problem, we all make mistakes, right?
>> > * Moderation rejected the announce mail quite harshly. I would agree that the missing links was reasonable cause to /hold back/ the announcement, but I think it was done in a way (tone and outright rejection instead of reaching out "hey, did you forget to update the download page?") that didn't invite to further communication. (I'm not comenting on the KEYS file issue, I wasn't around last time and I don't have the time to look up the policy, but from what I understand this was a minor issue).
>> >
>> > As far as I understand everyone in the Subversion project are volunteers. I don't know about the moderators but I assume they are as well. We need to treat eachother with respect and try to find the most efficient way for the community as a whole and not just "looking from the perspectiv of ****".
>> >
>> > Kind regards,
>> > Daniel Sahlberg
>>
>>
>> I agree that there needs to be respect and appreciation for everyone's
>> volunteer efforts here, and in the spirit of openness and cooperation
>> I have a suggestion to make:
>>
>> Since it seems that "not being spam" isn't enough to make an
>> announcement, and this is a long standing issue (it goes back farther
>> than last May), it would be immensely helpful, both for us and for the
>> moderators, if there were publicly posted rules that clearly outline:
>> "this is what moderators check; this is the criteria moderators use to
>> accept or reject an email to this list." This would clearly set
>> expectations and help to prevent the repeating issues that I'm sure
>> are frustrating to the list operators, and I know are frustrating for
>> us.
>>
>
> I agree that this would be useful.
>
> Where would you expect to find such information?
> And what rules would you expect to see?
>
> Remember that the announce@ list is ASF-wide, so emails need to be worded accordingly.
Ping... I'm writing to give an update and also a gentle nudge:
Update: On our (Subversion's) end, we are making some adjustments to
our release procedures and tooling to avoid the race-condition /
chicken-egg issue between download links and the announce email.
Nudge: On your (the list-owner's) end, have you had a chance to
document the criteria for announcements to be rejected or accepted?
Thanks,
Nathan
Re: Returned post for announce@apache.org
Posted by Nathan Hartman <ha...@gmail.com>.
On Sat, Feb 13, 2021 at 2:21 PM Daniel Sahlberg <da...@gmail.com>
wrote:
> Den lör 13 feb. 2021 kl 12:57 skrev Private List Moderation <
> mod-private@gsuite.cloud.apache.org>:
>
> And what rules would you expect to see?
>>
>
> Maybe this is too obvious but "the rules used by the moderators when
> deciding to reject a message". I don't think that the community would care
> too much about what these rules are as long as the rules are known
> beforehand (I'm speaking as community member, not being part of the PMC).
> The reason of the whole discussion as I understand it is a feeling that
> messages are arbitrary rejected. If there are clear rules, there can be a
> clear template for the RM to minimize the risk or rejection.
>
Exactly.
The moderators know what they check and when they accept or reject a
message. All we're asking is to have clarity on that, to make everyone's
lives easier.
Cheers,
Nathan
Re: Returned post for announce@apache.org
Posted by Daniel Sahlberg <da...@gmail.com>.
Den lör 13 feb. 2021 kl 12:57 skrev Private List Moderation <
mod-private@gsuite.cloud.apache.org>:
> I agree that this would be useful.
>
> Where would you expect to find such information?
>
I've searched and I can't find a really logical place. Maybe there is a
place with information for the projects that I can't find otherwise Cwiki
might be a good place. I would say it is most important that it is suitable
for the moderators. Wherever it is, we will link to it from our (
http://subversion.apache.org/docs/community-guide/releasing.html#releasing-release
).
And what rules would you expect to see?
>
Maybe this is too obvious but "the rules used by the moderators when
deciding to reject a message". I don't think that the community would care
too much about what these rules are as long as the rules are known
beforehand (I'm speaking as community member, not being part of the PMC).
The reason of the whole discussion as I understand it is a feeling that
messages are arbitrary rejected. If there are clear rules, there can be a
clear template for the RM to minimize the risk or rejection.
Remember that the announce@ list is ASF-wide, so emails need to be worded
> accordingly.
>
Absolutely, guidelines on appropriate messages are of course welcome.
Kind regards
Daniel Sahlberg
Re: Returned post for announce@apache.org
Posted by Private List Moderation <mo...@gsuite.cloud.apache.org>.
On Thu, 11 Feb 2021 at 19:24, Nathan Hartman <ha...@gmail.com>
wrote:
> On Thu, Feb 11, 2021 at 11:33 AM Daniel Sahlberg
> <da...@gmail.com> wrote:
> >
> > *thread reply*
> >
> > I think everyone should take a deep breath and then we should re-start
> the conversation with the purpose of learning and improving because at the
> moment it seems that emotions are way to high.
> >
> > As I see it - and as usual, I'm new to the party so I don't have
> historical context:
> >
> > * Subversion release process dictate to announce first, update website
> later. There is a reason for it but we can improve on the process. I've
> raised this at dev@ and received positive feedback from stsp.
> > * The RM an honest mistake and forgot to update the download page on the
> website. He has admitted and apologized. No problem, we all make mistakes,
> right?
> > * Moderation rejected the announce mail quite harshly. I would agree
> that the missing links was reasonable cause to /hold back/ the
> announcement, but I think it was done in a way (tone and outright rejection
> instead of reaching out "hey, did you forget to update the download page?")
> that didn't invite to further communication. (I'm not comenting on the KEYS
> file issue, I wasn't around last time and I don't have the time to look up
> the policy, but from what I understand this was a minor issue).
> >
> > As far as I understand everyone in the Subversion project are
> volunteers. I don't know about the moderators but I assume they are as
> well. We need to treat eachother with respect and try to find the most
> efficient way for the community as a whole and not just "looking from the
> perspectiv of ****".
> >
> > Kind regards,
> > Daniel Sahlberg
>
>
> I agree that there needs to be respect and appreciation for everyone's
> volunteer efforts here, and in the spirit of openness and cooperation
> I have a suggestion to make:
>
> Since it seems that "not being spam" isn't enough to make an
> announcement, and this is a long standing issue (it goes back farther
> than last May), it would be immensely helpful, both for us and for the
> moderators, if there were publicly posted rules that clearly outline:
> "this is what moderators check; this is the criteria moderators use to
> accept or reject an email to this list." This would clearly set
> expectations and help to prevent the repeating issues that I'm sure
> are frustrating to the list operators, and I know are frustrating for
> us.
>
>
I agree that this would be useful.
Where would you expect to find such information?
And what rules would you expect to see?
Remember that the announce@ list is ASF-wide, so emails need to be worded
accordingly.
Thanks to everyone for your support.
>
> Nathan
>
Re: Returned post for announce@apache.org
Posted by Nathan Hartman <ha...@gmail.com>.
On Thu, Feb 11, 2021 at 11:33 AM Daniel Sahlberg
<da...@gmail.com> wrote:
>
> *thread reply*
>
> I think everyone should take a deep breath and then we should re-start the conversation with the purpose of learning and improving because at the moment it seems that emotions are way to high.
>
> As I see it - and as usual, I'm new to the party so I don't have historical context:
>
> * Subversion release process dictate to announce first, update website later. There is a reason for it but we can improve on the process. I've raised this at dev@ and received positive feedback from stsp.
> * The RM an honest mistake and forgot to update the download page on the website. He has admitted and apologized. No problem, we all make mistakes, right?
> * Moderation rejected the announce mail quite harshly. I would agree that the missing links was reasonable cause to /hold back/ the announcement, but I think it was done in a way (tone and outright rejection instead of reaching out "hey, did you forget to update the download page?") that didn't invite to further communication. (I'm not comenting on the KEYS file issue, I wasn't around last time and I don't have the time to look up the policy, but from what I understand this was a minor issue).
>
> As far as I understand everyone in the Subversion project are volunteers. I don't know about the moderators but I assume they are as well. We need to treat eachother with respect and try to find the most efficient way for the community as a whole and not just "looking from the perspectiv of ****".
>
> Kind regards,
> Daniel Sahlberg
I agree that there needs to be respect and appreciation for everyone's
volunteer efforts here, and in the spirit of openness and cooperation
I have a suggestion to make:
Since it seems that "not being spam" isn't enough to make an
announcement, and this is a long standing issue (it goes back farther
than last May), it would be immensely helpful, both for us and for the
moderators, if there were publicly posted rules that clearly outline:
"this is what moderators check; this is the criteria moderators use to
accept or reject an email to this list." This would clearly set
expectations and help to prevent the repeating issues that I'm sure
are frustrating to the list operators, and I know are frustrating for
us.
Thanks to everyone for your support.
Nathan
Re: Returned post for announce@apache.org
Posted by Daniel Sahlberg <da...@gmail.com>.
*thread reply*
I think everyone should take a deep breath and then we should re-start the
conversation with the purpose of learning and improving because at the
moment it seems that emotions are way to high.
As I see it - and as usual, I'm new to the party so I don't have historical
context:
* Subversion release process dictate to announce first, update website
later. There is a reason for it but we can improve on the process. I've
raised this at dev@ and received positive feedback from stsp.
* The RM an honest mistake and forgot to update the download page on the
website. He has admitted and apologized. No problem, we all make mistakes,
right?
* Moderation rejected the announce mail quite harshly. I would agree that
the missing links was reasonable cause to /hold back/ the announcement, but
I think it was done in a way (tone and outright rejection instead of
reaching out "hey, did you forget to update the download page?") that
didn't invite to further communication. (I'm not comenting on the KEYS file
issue, I wasn't around last time and I don't have the time to look up the
policy, but from what I understand this was a minor issue).
As far as I understand everyone in the Subversion project are volunteers. I
don't know about the moderators but I assume they are as well. We need to
treat eachother with respect and try to find the most efficient way for the
community as a whole and not just "looking from the perspectiv of ****".
Kind regards,
Daniel Sahlberg
Re: Returned post for announce@apache.org
Posted by Erik Huelsmann <eh...@gmail.com>.
On Thu, Feb 11, 2021, 14:36 Private List Moderation <
mod-private@gsuite.cloud.apache.org> wrote:
> On Thu, 11 Feb 2021 at 12:15, Branko Čibej <br...@apache.org> wrote:
>
>> On 11.02.2021 12:23, Stefan Sperling wrote:
>>
>> On Thu, Feb 11, 2021 at 11:02:32AM +0000, Private List Moderation wrote:
>>
>> Irrelevant.
>>
>> Given that this discussion doesn't seem to be going anywhere and the
>> same arguments from May 2020 are just being rehashed, I guess we will
>> simply stop using the announce@ mailing list.
>>
>>
>> I agree. This nitpicking bureaucratic mission creep has gone way over the
>> top. We have our own announce@svn.a.o list anyway; I expect anyone who's
>> really interested is subscribed to that.
>>
>> I find it kind of ironically funny that the same moderator(s) who feel
>> they're empowered to enforce release policy don't feel that the normal
>> escalation path (i.e., bug report to dev@) is worth taking.
>>
>>
> There was a problem with the download page at the time it was checked.
>
What does a problem with the download page have to do with spam prevention?
Why does that problem make this spam?
Please try to see it from the moderator's point of view.
>
I can only look at it from my what I perceive to be the responsibility of a
moderator. And I am looking at it from that perspective.
Erik
Re: Returned post for announce@apache.org
Posted by Private List Moderation <mo...@gsuite.cloud.apache.org>.
On Thu, 11 Feb 2021 at 12:15, Branko Čibej <br...@apache.org> wrote:
> On 11.02.2021 12:23, Stefan Sperling wrote:
>
> On Thu, Feb 11, 2021 at 11:02:32AM +0000, Private List Moderation wrote:
>
> Irrelevant.
>
> Given that this discussion doesn't seem to be going anywhere and the
> same arguments from May 2020 are just being rehashed, I guess we will
> simply stop using the announce@ mailing list.
>
>
> I agree. This nitpicking bureaucratic mission creep has gone way over the
> top. We have our own announce@svn.a.o list anyway; I expect anyone who's
> really interested is subscribed to that.
>
> I find it kind of ironically funny that the same moderator(s) who feel
> they're empowered to enforce release policy don't feel that the normal
> escalation path (i.e., bug report to dev@) is worth taking.
>
>
There was a problem with the download page at the time it was checked.
This meant that the announce email could not be accepted.
The simplest and quickest way for the moderators to report this is to
reject the announce email.
This ensures that at least the RM gets the notification.
Yes, I could have sent a mail to the dev list instead, but that is more
work for the moderator.
It's not as if I blocked all future announce emails.
I merely rejected a single email.
Please try to see it from the moderator's point of view.
Meh.
>
> -- Brane
>
Re: Returned post for announce@apache.org
Posted by Nathan Hartman <ha...@gmail.com>.
On Thu, Feb 11, 2021 at 7:15 AM Branko Čibej <br...@apache.org> wrote:
> On 11.02.2021 12:23, Stefan Sperling wrote:
>
> On Thu, Feb 11, 2021 at 11:02:32AM +0000, Private List Moderation wrote:
>
> Irrelevant.
>
> Given that this discussion doesn't seem to be going anywhere and the
> same arguments from May 2020 are just being rehashed, I guess we will
> simply stop using the announce@ mailing list.
>
>
> I agree. This nitpicking bureaucratic mission creep has gone way over the
> top. We have our own announce@svn.a.o list anyway; I expect anyone who's
> really interested is subscribed to that.
>
[cc &= ~(dev@)]
Sounds good to me. We could just as easily link to the release announcement
on our announce list rather than the ASF-wide one.
Nathan
Re: Returned post for announce@apache.org
Posted by Branko Čibej <br...@apache.org>.
On 11.02.2021 12:23, Stefan Sperling wrote:
> On Thu, Feb 11, 2021 at 11:02:32AM +0000, Private List Moderation wrote:
>> Irrelevant.
> Given that this discussion doesn't seem to be going anywhere and the
> same arguments from May 2020 are just being rehashed, I guess we will
> simply stop using the announce@ mailing list.
I agree. This nitpicking bureaucratic mission creep has gone way over
the top. We have our own announce@svn.a.o list anyway; I expect anyone
who's really interested is subscribed to that.
I find it kind of ironically funny that the same moderator(s) who feel
they're empowered to enforce release policy don't feel that the normal
escalation path (i.e., bug report to dev@) is worth taking.
Meh.
-- Brane
Re: Returned post for announce@apache.org
Posted by Stefan Sperling <st...@apache.org>.
On Thu, Feb 11, 2021 at 11:02:32AM +0000, Private List Moderation wrote:
> Irrelevant.
Given that this discussion doesn't seem to be going anywhere and the
same arguments from May 2020 are just being rehashed, I guess we will
simply stop using the announce@ mailing list.
Re: Returned post for announce@apache.org
Posted by Private List Moderation <mo...@gsuite.cloud.apache.org>.
On Thu, 11 Feb 2021 at 07:04, Stefan Sperling <st...@apache.org> wrote:
> On Wed, Feb 10, 2021 at 11:03:39PM -0500, Nathan Hartman wrote:
> > On Wed, Feb 10, 2021 at 7:51 PM Private List Moderation <
> > mod-private@gsuite.cloud.apache.org> wrote:
> > > When I checked the download page, there were no links for versions
> 1.10.7
> > > or 1.14.1.
> > > i.e. the 2 announce mails were telling people to download versions that
> > > were not on the download page.
> > >
> > > As such, I felt I had to reject the announce email.
> > >
> > > It looks as though the page has since been updated.
> > >
> >
> >
> > That was a race condition.
>
> Worse, it's a chicken-and-egg problem which is documented here:
>
> http://subversion.apache.org/docs/community-guide/releasing.html#releasing-release
> """
> NOTE: We announce the release before updating the website since the
> website update links to the release announcement sent to the announce@
> mailing list.
> """
>
>
Which is worse for the end user?
- a broken link to the release announcement
- a missing link to the download artifact referenced by the official
announcement
The former could easily be avoided by noting that the announce mail may
take a few hours to reach the archives.
Notwithstanding that, yes, I did actually forget to update the download
> page immediately after posting the announcements. dsahlberg kindly reminded
> me of this. It still don't see how this is a reason for blocking a
> legitimate
> release annoucement. Instead of rejecting the annoucement outright you
> could
> have mailed us on dev@ with a question like "This looks incomplete. Are
> you
> sure you want to post this annoucement?". That would have been helpful, but
> moderation rejection is not helpful.
>
>
Rejecting an email is not the same as vetoing a release.
The moderators have a lot of mails to check.
It's easier from our point of view to reject the email intially, and check
again when a new email comes in.
Otherwise we have to keep track of which emails are pending.
It's not exactly difficult for the RM to send a fresh copy of the announce.
You would have to send an email to inform the moderators that the issue has
been fixed.
Not everyone relies on the download pages to find our releases.
>
At the moment I sent the announcement at least one distribution (Suse Linux)
> already had RPMs with the security fix ready to go because we had sent
> security
> pre-notifications in private about a week earlier.
>
Irrelevant.
Cheers,
> Stefan
>
Re: Returned post for announce@apache.org
Posted by Stefan Sperling <st...@stsp.name>.
On Thu, Feb 11, 2021 at 10:31:24AM +0100, Daniel Sahlberg wrote:
> Den tors 11 feb. 2021 kl 10:11 skrev Stefan Sperling <st...@apache.org>:
>
> > On Thu, Feb 11, 2021 at 09:57:23AM +0100, Daniel Sahlberg wrote:
> > > It is indeed a chicken-and-egg problem. However I would suggest to split
> > > this "updating the website" into two separate parts:
> > > 1. Updating the download page and possibly also adding a news item (with
> > a
> > > placeholder link to the release announcement) before the announcement.
> > > 2. After the release announcement has landed in lists.a.o, update the
> > news
> > > item with a proper link.
> > >
> > > If the website is updated in one batch after the announcement someone
> > might
> > > receive the announcement, immediately heading to the download page and
> > then
> > > not finding the announced release.
> >
> > Yes, that makes sense. Would you have time to update the web site
> > accordingly?
> >
>
> Sure, I'll make a suggestion in staging. Not today though.
>
>
> > Having just run through the steps, I must say that our release manager's
> > guide
> > has a rather low signal-to-noise ratio in its current form.
> > It may help to break some text into more paragraphs with meaningful
> > headers,
> > and/or perhaps put boxes around some of the details that don't really
> > matter
> > when someone is trying to get an overview of the procedure.
> >
>
> Since I'm new to the party, maybe I can try to understand the procedure and
> break it up, and you can tell me when I go wrong?
>
> Kind regards,
> Daniel
Yes, sure. I will gladly review what you come up with.
Cheers,
Stefan
Re: Returned post for announce@apache.org
Posted by Daniel Sahlberg <da...@gmail.com>.
Den tors 11 feb. 2021 kl 10:31 skrev Daniel Sahlberg <
daniel.l.sahlberg@gmail.com>:
> Den tors 11 feb. 2021 kl 10:11 skrev Stefan Sperling <st...@apache.org>:
>
>> On Thu, Feb 11, 2021 at 09:57:23AM +0100, Daniel Sahlberg wrote:
>> > It is indeed a chicken-and-egg problem. However I would suggest to split
>> > this "updating the website" into two separate parts:
>> > 1. Updating the download page and possibly also adding a news item
>> (with a
>> > placeholder link to the release announcement) before the announcement.
>> > 2. After the release announcement has landed in lists.a.o, update the
>> news
>> > item with a proper link.
>> >
>> > If the website is updated in one batch after the announcement someone
>> might
>> > receive the announcement, immediately heading to the download page and
>> then
>> > not finding the announced release.
>>
>> Yes, that makes sense. Would you have time to update the web site
>> accordingly?
>>
>
> Sure, I'll make a suggestion in staging. Not today though.
>
I've committed an initial suggestion in r1886494 (
http://subversion-staging.apache.org/docs/community-guide/releasing.html#releasing-release
).
Kind regards,
Daniel Sahlberg
>
Re: Returned post for announce@apache.org
Posted by Daniel Sahlberg <da...@gmail.com>.
Den tors 11 feb. 2021 kl 10:11 skrev Stefan Sperling <st...@apache.org>:
> On Thu, Feb 11, 2021 at 09:57:23AM +0100, Daniel Sahlberg wrote:
> > It is indeed a chicken-and-egg problem. However I would suggest to split
> > this "updating the website" into two separate parts:
> > 1. Updating the download page and possibly also adding a news item (with
> a
> > placeholder link to the release announcement) before the announcement.
> > 2. After the release announcement has landed in lists.a.o, update the
> news
> > item with a proper link.
> >
> > If the website is updated in one batch after the announcement someone
> might
> > receive the announcement, immediately heading to the download page and
> then
> > not finding the announced release.
>
> Yes, that makes sense. Would you have time to update the web site
> accordingly?
>
Sure, I'll make a suggestion in staging. Not today though.
> Having just run through the steps, I must say that our release manager's
> guide
> has a rather low signal-to-noise ratio in its current form.
> It may help to break some text into more paragraphs with meaningful
> headers,
> and/or perhaps put boxes around some of the details that don't really
> matter
> when someone is trying to get an overview of the procedure.
>
Since I'm new to the party, maybe I can try to understand the procedure and
break it up, and you can tell me when I go wrong?
Kind regards,
Daniel
Re: Returned post for announce@apache.org
Posted by Stefan Sperling <st...@apache.org>.
On Thu, Feb 11, 2021 at 09:57:23AM +0100, Daniel Sahlberg wrote:
> It is indeed a chicken-and-egg problem. However I would suggest to split
> this "updating the website" into two separate parts:
> 1. Updating the download page and possibly also adding a news item (with a
> placeholder link to the release announcement) before the announcement.
> 2. After the release announcement has landed in lists.a.o, update the news
> item with a proper link.
>
> If the website is updated in one batch after the announcement someone might
> receive the announcement, immediately heading to the download page and then
> not finding the announced release.
Yes, that makes sense. Would you have time to update the web site accordingly?
Having just run through the steps, I must say that our release manager's guide
has a rather low signal-to-noise ratio in its current form.
It may help to break some text into more paragraphs with meaningful headers,
and/or perhaps put boxes around some of the details that don't really matter
when someone is trying to get an overview of the procedure.
Regards,
Stefan
Re: Returned post for announce@apache.org
Posted by Daniel Sahlberg <da...@gmail.com>.
[[ Continuing the discussion on dev@ only since I intend to discuss website
update policy and not the current release ]]
Den tors 11 feb. 2021 kl 08:04 skrev Stefan Sperling <st...@apache.org>:
> On Wed, Feb 10, 2021 at 11:03:39PM -0500, Nathan Hartman wrote:
> > On Wed, Feb 10, 2021 at 7:51 PM Private List Moderation <
> > mod-private@gsuite.cloud.apache.org> wrote:
> > > When I checked the download page, there were no links for versions
> 1.10.7
> > > or 1.14.1.
> > > i.e. the 2 announce mails were telling people to download versions that
> > > were not on the download page.
> > >
> > > As such, I felt I had to reject the announce email.
> > >
> > > It looks as though the page has since been updated.
> > >
> >
> >
> > That was a race condition.
>
> Worse, it's a chicken-and-egg problem which is documented here:
>
> http://subversion.apache.org/docs/community-guide/releasing.html#releasing-release
> """
> NOTE: We announce the release before updating the website since the
> website update links to the release announcement sent to the announce@
> mailing list.
> """
>
It is indeed a chicken-and-egg problem. However I would suggest to split
this "updating the website" into two separate parts:
1. Updating the download page and possibly also adding a news item (with a
placeholder link to the release announcement) before the announcement.
2. After the release announcement has landed in lists.a.o, update the news
item with a proper link.
If the website is updated in one batch after the announcement someone might
receive the announcement, immediately heading to the download page and then
not finding the announced release.
Stefan actually added the news item with a placeholder in a separate commit
and then added the proper link afterwards so I hope it wouldn't increase
the burden to much on release manager if sending the release announcement
is moved in the middle of updating the website.
One could argue that the time period when the download page is not updated
is relatively short but I think it should be possible to avoid this problem
altogether.
Not everyone relies on the download pages to find our releases.
>
I agree with this assessment, but sometimes the people who don't understand
the process are the most vocal.
Kind regards,
Daniel Sahlberg
Re: Returned post for announce@apache.org
Posted by Stefan Sperling <st...@apache.org>.
On Wed, Feb 10, 2021 at 11:03:39PM -0500, Nathan Hartman wrote:
> On Wed, Feb 10, 2021 at 7:51 PM Private List Moderation <
> mod-private@gsuite.cloud.apache.org> wrote:
> > When I checked the download page, there were no links for versions 1.10.7
> > or 1.14.1.
> > i.e. the 2 announce mails were telling people to download versions that
> > were not on the download page.
> >
> > As such, I felt I had to reject the announce email.
> >
> > It looks as though the page has since been updated.
> >
>
>
> That was a race condition.
Worse, it's a chicken-and-egg problem which is documented here:
http://subversion.apache.org/docs/community-guide/releasing.html#releasing-release
"""
NOTE: We announce the release before updating the website since the
website update links to the release announcement sent to the announce@
mailing list.
"""
Notwithstanding that, yes, I did actually forget to update the download
page immediately after posting the announcements. dsahlberg kindly reminded
me of this. It still don't see how this is a reason for blocking a legitimate
release annoucement. Instead of rejecting the annoucement outright you could
have mailed us on dev@ with a question like "This looks incomplete. Are you
sure you want to post this annoucement?". That would have been helpful, but
moderation rejection is not helpful.
Not everyone relies on the download pages to find our releases.
At the moment I sent the announcement at least one distribution (Suse Linux)
already had RPMs with the security fix ready to go because we had sent security
pre-notifications in private about a week earlier.
Cheers,
Stefan
Re: Returned post for announce@apache.org
Posted by Private List Moderation <mo...@gsuite.cloud.apache.org>.
On Thu, 11 Feb 2021 at 04:03, Nathan Hartman <ha...@gmail.com>
wrote:
> On Wed, Feb 10, 2021 at 7:51 PM Private List Moderation <
> mod-private@gsuite.cloud.apache.org> wrote:
>
>> On Wed, 10 Feb 2021 at 22:26, Erik Huelsmann <eh...@gmail.com> wrote:
>>
>>> How can a link be more important than an announcement for a fix of an
>>> *unauthenticated* remote DoS ?
>>>
>>>
>> When I checked the download page, there were no links for versions 1.10.7
>> or 1.14.1.
>> i.e. the 2 announce mails were telling people to download versions that
>> were not on the download page.
>>
>> As such, I felt I had to reject the announce email.
>>
>> It looks as though the page has since been updated.
>>
>
>
> That was a race condition.
>
>
As the issue is fixed, would you please allow the message through now?
>
Once an email has been rejected, it cannot be accepted.
Do we need to re-send it?
>
>
As I wrote in both rejection comments, a corrected email needs to be sent.
Thank you,
> Nathan Hartman
> V.P., Subversion
>
>
Re: Returned post for announce@apache.org
Posted by Nathan Hartman <ha...@gmail.com>.
On Wed, Feb 10, 2021 at 7:51 PM Private List Moderation <
mod-private@gsuite.cloud.apache.org> wrote:
> On Wed, 10 Feb 2021 at 22:26, Erik Huelsmann <eh...@gmail.com> wrote:
>
>> How can a link be more important than an announcement for a fix of an
>> *unauthenticated* remote DoS ?
>>
>>
> When I checked the download page, there were no links for versions 1.10.7
> or 1.14.1.
> i.e. the 2 announce mails were telling people to download versions that
> were not on the download page.
>
> As such, I felt I had to reject the announce email.
>
> It looks as though the page has since been updated.
>
That was a race condition.
As the issue is fixed, would you please allow the message through now? Do
we need to re-send it?
Thank you,
Nathan Hartman
V.P., Subversion
Re: Returned post for announce@apache.org
Posted by Private List Moderation <mo...@gsuite.cloud.apache.org>.
On Wed, 10 Feb 2021 at 22:26, Erik Huelsmann <eh...@gmail.com> wrote:
> How can a link be more important than an announcement for a fix of an
> *unauthenticated* remote DoS ?
>
>
When I checked the download page, there were no links for versions 1.10.7
or 1.14.1.
i.e. the 2 announce mails were telling people to download versions that
were not on the download page.
As such, I felt I had to reject the announce email.
It looks as though the page has since been updated.
Same for the KEYS file???
>
>
I never said that was equally important.
Don't you think that's way out of proportion?
>
> Erik.
>
> On Wed, Feb 10, 2021 at 4:50 PM Private List Moderation
> <mo...@gsuite.cloud.apache.org> wrote:
> >
> > I don't see how the missing links can be regarded as trivial.
> > This obviously needs to be fixed before the announce can be accepted.
> >
> > At the same time, I asked for the KEYS file link to be standardised.
> > There is already a KEYS file at the standard location - why not link to
> that instead?
> >
> >
> > On Wed, 10 Feb 2021 at 15:35, Stefan Sperling <st...@apache.org> wrote:
> >>
> >> Sebb, blocking our release announcements over trivialities like this
> >> really is not a nice thing to do. Last time it happened in May 2020.
> >> It was already discussed back then and raised with the announce@
> >> moderation team.
> >>
> >> The Subversion PMC came to the conclusion that our handling of
> >> the KEYS files is adequate for our purposes:
> >> https://svn.haxx.se/dev/archive-2020-05/0156.shtml
> >>
> >> Please raise the issue on our dev@subversion.a.o list if it bothers
> you.
> >> The moderation mechanism is supposed to prevent spam. Using it to
> enforce
> >> release workflow policies amounts to misuse of your moderation
> privileges.
> >>
> >> Regards,
> >> Stefan
> >>
> >> On Wed, Feb 10, 2021 at 03:20:41PM -0000, announce-owner@apache.org
> wrote:
> >> >
> >> > Hi! This is the ezmlm program. I'm managing the
> >> > announce@apache.org mailing list.
> >> >
> >> > I'm working for my owner, who can be reached
> >> > at announce-owner@apache.org.
> >> >
> >> > I'm sorry, your message (enclosed) was not accepted by the moderator.
> >> > If the moderator has made any comments, they are shown below.
> >> >
> >> > >>>>> -------------------- >>>>>
> >> > Sorry, but the announce cannot be accepted.
> >> > The linked download page does not contain links for the version in the
> >> > email.
> >> >
> >> > Also, the standard name for the KEYS file is KEYS - no prefix, no
> suffix.
> >> > Please correct the download page, check it, and submit a corrected
> announce
> >> > mail.
> >> >
> >> > Thanks,
> >> > Sebb.
> >> > <<<<< -------------------- <<<<<
> >> >
> >>
> >> > Date: Wed, 10 Feb 2021 14:37:00 +0100
> >> > From: Stefan Sperling <st...@apache.org>
> >> > To: announce@subversion.apache.org, users@subversion.apache.org,
> >> > dev@subversion.apache.org, announce@apache.org
> >> > Cc: security@apache.org, oss-security@lists.openwall.com,
> >> > bugtraq@securityfocus.com
> >> > Subject: [SECURITY][ANNOUNCE] Apache Subversion 1.10.7 released
> >> > Message-ID: <YC...@byrne.stsp.name>
> >> > Reply-To: users@subversion.apache.org
> >> > Content-Type: text/plain; charset=utf-8
> >> >
> >> > I'm happy to announce the release of Apache Subversion 1.10.7.
> >> > Please choose the mirror closest to you by visiting:
> >> >
> >> > https://subversion.apache.org/download.cgi#supported-releases
> >> >
> >> > This is a stable bugfix and security release of the Apache Subversion
> >> > open source version control system.
> >> >
> >> > THIS RELEASE CONTAINS AN IMPORTANT SECURITY FIX:
> >> >
> >> > CVE-2020-17525
> >> > "Remote unauthenticated denial-of-service in Subversion
> mod_authz_svn"
> >> >
> >> > The full security advisory for CVE-2020-17525 is available at:
> >> > https://subversion.apache.org/security/CVE-2020-17525-advisory.txt
> >> >
> >> > A brief summary of this advisory follows:
> >> >
> >> > Subversion's mod_authz_svn module will crash if the server is using
> >> > in-repository authz rules with the AuthzSVNReposRelativeAccessFile
> >> > option and a client sends a request for a non-existing repository
> URL.
> >> >
> >> > This can lead to disruption for users of the service.
> >> >
> >> > We recommend all users to upgrade to the 1.10.7 or 1.14.1 release
> >> > of the Subversion mod_dav_svn server.
> >> >
> >> > As a workaround, the use of in-repository authz rules files with
> >> > the AuthzSVNReposRelativeAccessFile can be avoided by switching
> >> > to an alternative configuration which fetches an authz rules file
> >> > from the server's filesystem, rather than from an SVN repository.
> >> >
> >> > This issue was reported by Thomas Åkesson.
> >> >
> >> > SHA-512 checksums are available at:
> >> >
> >> >
> https://www.apache.org/dist/subversion/subversion-1.10.7.tar.bz2.sha512
> >> >
> https://www.apache.org/dist/subversion/subversion-1.10.7.tar.gz.sha512
> >> >
> https://www.apache.org/dist/subversion/subversion-1.10.7.zip.sha512
> >> >
> >> > PGP Signatures are available at:
> >> >
> >> >
> https://www.apache.org/dist/subversion/subversion-1.10.7.tar.bz2.asc
> >> >
> https://www.apache.org/dist/subversion/subversion-1.10.7.tar.gz.asc
> >> > https://www.apache.org/dist/subversion/subversion-1.10.7.zip.asc
> >> >
> >> > For this release, the following people have provided PGP signatures:
> >> >
> >> > Stefan Sperling [2048R/4F7DBAA99A59B973] with fingerprint:
> >> > 8BC4 DAE0 C5A4 D65F 4044 0107 4F7D BAA9 9A59 B973
> >> > Branko Čibej [4096R/1BCA6586A347943F] with fingerprint:
> >> > BA3C 15B1 337C F0FB 222B D41A 1BCA 6586 A347 943F
> >> > Johan Corveleyn [4096R/B59CE6D6010C8AAD] with fingerprint:
> >> > 8AA2 C10E EAAD 44F9 6972 7AEA B59C E6D6 010C 8AAD
> >> >
> >> > These public keys are available at:
> >> >
> >> > https://www.apache.org/dist/subversion/subversion-1.10.7.KEYS
> >> >
> >> > Release notes for the 1.10.x release series may be found at:
> >> >
> >> > https://subversion.apache.org/docs/release-notes/1.10.html
> >> >
> >> > You can find the list of changes between 1.10.7 and earlier versions
> at:
> >> >
> >> > https://svn.apache.org/repos/asf/subversion/tags/1.10.7/CHANGES
> >> >
> >> > Questions, comments, and bug reports to users@subversion.apache.org.
> >> >
> >> > Thanks,
> >> > - The Subversion Team
> >> >
> >> > --
> >> > To unsubscribe, please see:
> >> >
> >> > https://subversion.apache.org/mailing-lists.html#unsubscribing
> >> >
> >>
>
>
> --
> Bye,
>
> Erik.
>
> http://efficito.com -- Hosted accounting and ERP.
> Robust and Flexible. No vendor lock-in.
>
Re: Returned post for announce@apache.org
Posted by Erik Huelsmann <eh...@gmail.com>.
How can a link be more important than an announcement for a fix of an
*unauthenticated* remote DoS ?
Same for the KEYS file???
Don't you think that's way out of proportion?
Erik.
On Wed, Feb 10, 2021 at 4:50 PM Private List Moderation
<mo...@gsuite.cloud.apache.org> wrote:
>
> I don't see how the missing links can be regarded as trivial.
> This obviously needs to be fixed before the announce can be accepted.
>
> At the same time, I asked for the KEYS file link to be standardised.
> There is already a KEYS file at the standard location - why not link to that instead?
>
>
> On Wed, 10 Feb 2021 at 15:35, Stefan Sperling <st...@apache.org> wrote:
>>
>> Sebb, blocking our release announcements over trivialities like this
>> really is not a nice thing to do. Last time it happened in May 2020.
>> It was already discussed back then and raised with the announce@
>> moderation team.
>>
>> The Subversion PMC came to the conclusion that our handling of
>> the KEYS files is adequate for our purposes:
>> https://svn.haxx.se/dev/archive-2020-05/0156.shtml
>>
>> Please raise the issue on our dev@subversion.a.o list if it bothers you.
>> The moderation mechanism is supposed to prevent spam. Using it to enforce
>> release workflow policies amounts to misuse of your moderation privileges.
>>
>> Regards,
>> Stefan
>>
>> On Wed, Feb 10, 2021 at 03:20:41PM -0000, announce-owner@apache.org wrote:
>> >
>> > Hi! This is the ezmlm program. I'm managing the
>> > announce@apache.org mailing list.
>> >
>> > I'm working for my owner, who can be reached
>> > at announce-owner@apache.org.
>> >
>> > I'm sorry, your message (enclosed) was not accepted by the moderator.
>> > If the moderator has made any comments, they are shown below.
>> >
>> > >>>>> -------------------- >>>>>
>> > Sorry, but the announce cannot be accepted.
>> > The linked download page does not contain links for the version in the
>> > email.
>> >
>> > Also, the standard name for the KEYS file is KEYS - no prefix, no suffix.
>> > Please correct the download page, check it, and submit a corrected announce
>> > mail.
>> >
>> > Thanks,
>> > Sebb.
>> > <<<<< -------------------- <<<<<
>> >
>>
>> > Date: Wed, 10 Feb 2021 14:37:00 +0100
>> > From: Stefan Sperling <st...@apache.org>
>> > To: announce@subversion.apache.org, users@subversion.apache.org,
>> > dev@subversion.apache.org, announce@apache.org
>> > Cc: security@apache.org, oss-security@lists.openwall.com,
>> > bugtraq@securityfocus.com
>> > Subject: [SECURITY][ANNOUNCE] Apache Subversion 1.10.7 released
>> > Message-ID: <YC...@byrne.stsp.name>
>> > Reply-To: users@subversion.apache.org
>> > Content-Type: text/plain; charset=utf-8
>> >
>> > I'm happy to announce the release of Apache Subversion 1.10.7.
>> > Please choose the mirror closest to you by visiting:
>> >
>> > https://subversion.apache.org/download.cgi#supported-releases
>> >
>> > This is a stable bugfix and security release of the Apache Subversion
>> > open source version control system.
>> >
>> > THIS RELEASE CONTAINS AN IMPORTANT SECURITY FIX:
>> >
>> > CVE-2020-17525
>> > "Remote unauthenticated denial-of-service in Subversion mod_authz_svn"
>> >
>> > The full security advisory for CVE-2020-17525 is available at:
>> > https://subversion.apache.org/security/CVE-2020-17525-advisory.txt
>> >
>> > A brief summary of this advisory follows:
>> >
>> > Subversion's mod_authz_svn module will crash if the server is using
>> > in-repository authz rules with the AuthzSVNReposRelativeAccessFile
>> > option and a client sends a request for a non-existing repository URL.
>> >
>> > This can lead to disruption for users of the service.
>> >
>> > We recommend all users to upgrade to the 1.10.7 or 1.14.1 release
>> > of the Subversion mod_dav_svn server.
>> >
>> > As a workaround, the use of in-repository authz rules files with
>> > the AuthzSVNReposRelativeAccessFile can be avoided by switching
>> > to an alternative configuration which fetches an authz rules file
>> > from the server's filesystem, rather than from an SVN repository.
>> >
>> > This issue was reported by Thomas Åkesson.
>> >
>> > SHA-512 checksums are available at:
>> >
>> > https://www.apache.org/dist/subversion/subversion-1.10.7.tar.bz2.sha512
>> > https://www.apache.org/dist/subversion/subversion-1.10.7.tar.gz.sha512
>> > https://www.apache.org/dist/subversion/subversion-1.10.7.zip.sha512
>> >
>> > PGP Signatures are available at:
>> >
>> > https://www.apache.org/dist/subversion/subversion-1.10.7.tar.bz2.asc
>> > https://www.apache.org/dist/subversion/subversion-1.10.7.tar.gz.asc
>> > https://www.apache.org/dist/subversion/subversion-1.10.7.zip.asc
>> >
>> > For this release, the following people have provided PGP signatures:
>> >
>> > Stefan Sperling [2048R/4F7DBAA99A59B973] with fingerprint:
>> > 8BC4 DAE0 C5A4 D65F 4044 0107 4F7D BAA9 9A59 B973
>> > Branko Čibej [4096R/1BCA6586A347943F] with fingerprint:
>> > BA3C 15B1 337C F0FB 222B D41A 1BCA 6586 A347 943F
>> > Johan Corveleyn [4096R/B59CE6D6010C8AAD] with fingerprint:
>> > 8AA2 C10E EAAD 44F9 6972 7AEA B59C E6D6 010C 8AAD
>> >
>> > These public keys are available at:
>> >
>> > https://www.apache.org/dist/subversion/subversion-1.10.7.KEYS
>> >
>> > Release notes for the 1.10.x release series may be found at:
>> >
>> > https://subversion.apache.org/docs/release-notes/1.10.html
>> >
>> > You can find the list of changes between 1.10.7 and earlier versions at:
>> >
>> > https://svn.apache.org/repos/asf/subversion/tags/1.10.7/CHANGES
>> >
>> > Questions, comments, and bug reports to users@subversion.apache.org.
>> >
>> > Thanks,
>> > - The Subversion Team
>> >
>> > --
>> > To unsubscribe, please see:
>> >
>> > https://subversion.apache.org/mailing-lists.html#unsubscribing
>> >
>>
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
Re: Returned post for announce@apache.org
Posted by Private List Moderation <mo...@gsuite.cloud.apache.org>.
I don't see how the missing links can be regarded as trivial.
This obviously needs to be fixed before the announce can be accepted.
At the same time, I asked for the KEYS file link to be standardised.
There is already a KEYS file at the standard location - why not link to
that instead?
On Wed, 10 Feb 2021 at 15:35, Stefan Sperling <st...@apache.org> wrote:
> Sebb, blocking our release announcements over trivialities like this
> really is not a nice thing to do. Last time it happened in May 2020.
> It was already discussed back then and raised with the announce@
> moderation team.
>
> The Subversion PMC came to the conclusion that our handling of
> the KEYS files is adequate for our purposes:
> https://svn.haxx.se/dev/archive-2020-05/0156.shtml
>
> Please raise the issue on our dev@subversion.a.o list if it bothers you.
> The moderation mechanism is supposed to prevent spam. Using it to enforce
> release workflow policies amounts to misuse of your moderation privileges.
>
> Regards,
> Stefan
>
> On Wed, Feb 10, 2021 at 03:20:41PM -0000, announce-owner@apache.org wrote:
> >
> > Hi! This is the ezmlm program. I'm managing the
> > announce@apache.org mailing list.
> >
> > I'm working for my owner, who can be reached
> > at announce-owner@apache.org.
> >
> > I'm sorry, your message (enclosed) was not accepted by the moderator.
> > If the moderator has made any comments, they are shown below.
> >
> > >>>>> -------------------- >>>>>
> > Sorry, but the announce cannot be accepted.
> > The linked download page does not contain links for the version in the
> > email.
> >
> > Also, the standard name for the KEYS file is KEYS - no prefix, no suffix.
> > Please correct the download page, check it, and submit a corrected
> announce
> > mail.
> >
> > Thanks,
> > Sebb.
> > <<<<< -------------------- <<<<<
> >
>
> > Date: Wed, 10 Feb 2021 14:37:00 +0100
> > From: Stefan Sperling <st...@apache.org>
> > To: announce@subversion.apache.org, users@subversion.apache.org,
> > dev@subversion.apache.org, announce@apache.org
> > Cc: security@apache.org, oss-security@lists.openwall.com,
> > bugtraq@securityfocus.com
> > Subject: [SECURITY][ANNOUNCE] Apache Subversion 1.10.7 released
> > Message-ID: <YC...@byrne.stsp.name>
> > Reply-To: users@subversion.apache.org
> > Content-Type: text/plain; charset=utf-8
> >
> > I'm happy to announce the release of Apache Subversion 1.10.7.
> > Please choose the mirror closest to you by visiting:
> >
> > https://subversion.apache.org/download.cgi#supported-releases
> >
> > This is a stable bugfix and security release of the Apache Subversion
> > open source version control system.
> >
> > THIS RELEASE CONTAINS AN IMPORTANT SECURITY FIX:
> >
> > CVE-2020-17525
> > "Remote unauthenticated denial-of-service in Subversion mod_authz_svn"
> >
> > The full security advisory for CVE-2020-17525 is available at:
> > https://subversion.apache.org/security/CVE-2020-17525-advisory.txt
> >
> > A brief summary of this advisory follows:
> >
> > Subversion's mod_authz_svn module will crash if the server is using
> > in-repository authz rules with the AuthzSVNReposRelativeAccessFile
> > option and a client sends a request for a non-existing repository URL.
> >
> > This can lead to disruption for users of the service.
> >
> > We recommend all users to upgrade to the 1.10.7 or 1.14.1 release
> > of the Subversion mod_dav_svn server.
> >
> > As a workaround, the use of in-repository authz rules files with
> > the AuthzSVNReposRelativeAccessFile can be avoided by switching
> > to an alternative configuration which fetches an authz rules file
> > from the server's filesystem, rather than from an SVN repository.
> >
> > This issue was reported by Thomas Åkesson.
> >
> > SHA-512 checksums are available at:
> >
> >
> https://www.apache.org/dist/subversion/subversion-1.10.7.tar.bz2.sha512
> >
> https://www.apache.org/dist/subversion/subversion-1.10.7.tar.gz.sha512
> > https://www.apache.org/dist/subversion/subversion-1.10.7.zip.sha512
> >
> > PGP Signatures are available at:
> >
> > https://www.apache.org/dist/subversion/subversion-1.10.7.tar.bz2.asc
> > https://www.apache.org/dist/subversion/subversion-1.10.7.tar.gz.asc
> > https://www.apache.org/dist/subversion/subversion-1.10.7.zip.asc
> >
> > For this release, the following people have provided PGP signatures:
> >
> > Stefan Sperling [2048R/4F7DBAA99A59B973] with fingerprint:
> > 8BC4 DAE0 C5A4 D65F 4044 0107 4F7D BAA9 9A59 B973
> > Branko Čibej [4096R/1BCA6586A347943F] with fingerprint:
> > BA3C 15B1 337C F0FB 222B D41A 1BCA 6586 A347 943F
> > Johan Corveleyn [4096R/B59CE6D6010C8AAD] with fingerprint:
> > 8AA2 C10E EAAD 44F9 6972 7AEA B59C E6D6 010C 8AAD
> >
> > These public keys are available at:
> >
> > https://www.apache.org/dist/subversion/subversion-1.10.7.KEYS
> >
> > Release notes for the 1.10.x release series may be found at:
> >
> > https://subversion.apache.org/docs/release-notes/1.10.html
> >
> > You can find the list of changes between 1.10.7 and earlier versions at:
> >
> > https://svn.apache.org/repos/asf/subversion/tags/1.10.7/CHANGES
> >
> > Questions, comments, and bug reports to users@subversion.apache.org.
> >
> > Thanks,
> > - The Subversion Team
> >
> > --
> > To unsubscribe, please see:
> >
> > https://subversion.apache.org/mailing-lists.html#unsubscribing
> >
>
>