You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@apache.org> on 2019/03/12 16:34:20 UTC
Link to KEYS file on our download page
Hello, devs. Apparently our handling of the KEYS file needs to change: see below.
Is anybody willing to handle this?
- Julian
----- Original message -----
From: announce-owner@apache.org
Subject: Returned post for announce@apache.org
Sorry, but the download page is missing a required link to the KEYS file.
The URL must be of the form: https://www.apache.org/dist/<project>/KEYS
Links to http://people.apache.org/ are not acceptable; see the note here:
https://people.apache.org/keys/
Please resubmit the announce email when this has been corrected.
Thanks,
Sebb
Re: Link to KEYS file on our download page
Posted by sebb <se...@gmail.com>.
On Wed, 13 Mar 2019 at 15:42, sebb <se...@gmail.com> wrote:
>
> On Wed, 13 Mar 2019 at 15:15, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> >
> > [ removing dev@svn, adding dev@whimsy — sorry if that's not the right list. ]
> >
> > Sebb,
> >
> > KEYS formats have multiple problems. They are a custom format that
> > needs to be updated by hand, and if someone is a committer on N projects
> > then he needs to do O(N) work to update their keys. That's a very poor design
> > from a human factors point of view.
>
> They only need to add their key on projects where they have signed a release.
>
> That is a much smaller number.
>
> > p.a.o/keys/ was invented to solve these problems. If it has downsides,
> > fine, but don't throw the baby out with the bathwater.
> >
> > It would be better to change the p.a.o/keys/ cron job (1) to work, not
> > off of LDAP but off of an append-only dataset mapping PMCs to committers
> > and committers to keys; and (2) instead of publishing the results on
> > minotaur, to auto-commit them to /repos/dist/$PMC/release/KEYS.
>
> I think that will cause problems.
>
> KEYS are used for archives validation as well.
> Entries should not be deleted if they have ever been used to sign a release.
>
> KEYS will grow and grow.
> That is not very friendly to downloaders who want to use the KEYS file.
>
> Also I am wary about allowing a bot to update the KEYS file.
> The provenance of the data is not nearly so easy to establish.
Also, not all projects have a KEYS file in the canonical location (
/repos/dist/$PMC/release/KEYS)
And some projects maintain the KEYS file elsewhere and copy it to the
canonical location.
However, if there really is an issue with the work needed to update
the KEYS files, then maybe there could be a tool to make it easier for
a release signer to add their key to whatever KEYS file is maintained
by their project.
> Sebb.
Re: Link to KEYS file on our download page
Posted by Julian Foad <ju...@apache.org>.
Please let's encourage anyone who wants to help, to automate this.
Managing keys distribution manually is grunt work, not something I want to be doing myself, not something I want other ASF committers to be doing. As a contributing factor to the development of our open source software, it's a negative. It lends itself well to being managed consistently across all projects [1]. Speaking for myself, I want this automated. Even a crude automation would be better than none.
Can we move forward by accepting some automation as better than none?
- Julian
[1] It doesn't have to be mandatory.
Re: Link to KEYS file on our download page
Posted by sebb <se...@gmail.com>.
On Wed, 13 Mar 2019 at 17:26, Daniel Shahaf <da...@apache.org> wrote:
>
> On Wed, Mar 13, 2019 at 03:42:13PM +0000, sebb wrote:
> > On Wed, 13 Mar 2019 at 15:15, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > >
> > > [ removing dev@svn, adding dev@whimsy — sorry if that's not the right list. ]
> > >
> > > Sebb,
> > >
> > > KEYS formats have multiple problems. They are a custom format that
> > > needs to be updated by hand, and if someone is a committer on N projects
> > > then he needs to do O(N) work to update their keys. That's a very poor design
> > > from a human factors point of view.
> >
> > They only need to add their key on projects where they have signed a release.
> >
> > That is a much smaller number.
> >
>
> It's still O(N⋅M) work that you are inflicting on everyone, year on year,
where M is nearly the same as N, I think.
> whereas the solution I proposed is O(1) work, one time. Also, you require
> everyone to keep state:
>
> "Oh, new serf release. Let me sign it. Hmm, have I signed a serf release
> since I created my new annual signing subkey?…"
Not really.
It will be obvious if they need to add their key when the release vote
is performed.
AIUI there is a script to check that the KEYS file contains the keys
necessary to validate releases.
> > > p.a.o/keys/ was invented to solve these problems. If it has downsides,
> > > fine, but don't throw the baby out with the bathwater.
> > >
> > > It would be better to change the p.a.o/keys/ cron job (1) to work, not
> > > off of LDAP but off of an append-only dataset mapping PMCs to committers
> > > and committers to keys; and (2) instead of publishing the results on
> > > minotaur, to auto-commit them to /repos/dist/$PMC/release/KEYS.
> >
> > I think that will cause problems.
> >
> > KEYS are used for archives validation as well.
> > Entries should not be deleted if they have ever been used to sign a release.
>
> You haven't actually explained what problem you see here in context of my
> proposal. Did you see the words "append-only" in my proposal? Did you observe
> how my prototype code creates an append-only set of unix names? The same would
> be done with the lists of committers per PMC and keyids per committer. Thus
> the files would be append-only (not in the line-based, 'echo >>' sense but in
> the set-of-OpenPGP-packets sense).
> Also, it is not a law of nature that each project shall have exactly one KEYS
> file for all their releases, current and historical. It's simply a system that
> somebody wrote up fifteen years ago, and it has its bugs. Just to illustrate
> how arbitrary the current system is, why shouldn't there be a convention that
> foo.tar.gz be accompanied by foo.tar.gz.keys? That file would be created as
> a symlink to some file that contains all the right keys. Each PMC could have,
> say, one KEYS file per year, and each release's .keys symlink would target the
> appropriate KEYS file.
>
> > KEYS will grow and grow.
> No, they won't.
It will certainly grow at least once when all project ids are added.
> /keys/group/foo.asc and /dist/release/foo/KEYS contain the same data.
No, KEYS will be bigger because it needs to contain historical keys.
The corresponding committers might not even exist in LDAP.
Note also that RMs are not necessarily members of the PMC.
This increases the potential size of the KEYS file by a large amount
for some PMCs.
> > Also I am wary about allowing a bot to update the KEYS file.
> > The provenance of the data is not nearly so easy to establish.
>
> The PGP security model does not require public keys to be transported over an
> authenticated channel.
Yes, but that only works for keys which have been countersigned.
AFAIK the vast majority have not been.
> Daniel
Re: Link to KEYS file on our download page
Posted by Daniel Shahaf <da...@apache.org>.
On Wed, Mar 13, 2019 at 03:42:13PM +0000, sebb wrote:
> On Wed, 13 Mar 2019 at 15:15, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> >
> > [ removing dev@svn, adding dev@whimsy — sorry if that's not the right list. ]
> >
> > Sebb,
> >
> > KEYS formats have multiple problems. They are a custom format that
> > needs to be updated by hand, and if someone is a committer on N projects
> > then he needs to do O(N) work to update their keys. That's a very poor design
> > from a human factors point of view.
>
> They only need to add their key on projects where they have signed a release.
>
> That is a much smaller number.
>
It's still O(N⋅M) work that you are inflicting on everyone, year on year,
whereas the solution I proposed is O(1) work, one time. Also, you require
everyone to keep state:
"Oh, new serf release. Let me sign it. Hmm, have I signed a serf release
since I created my new annual signing subkey?…"
> > p.a.o/keys/ was invented to solve these problems. If it has downsides,
> > fine, but don't throw the baby out with the bathwater.
> >
> > It would be better to change the p.a.o/keys/ cron job (1) to work, not
> > off of LDAP but off of an append-only dataset mapping PMCs to committers
> > and committers to keys; and (2) instead of publishing the results on
> > minotaur, to auto-commit them to /repos/dist/$PMC/release/KEYS.
>
> I think that will cause problems.
>
> KEYS are used for archives validation as well.
> Entries should not be deleted if they have ever been used to sign a release.
You haven't actually explained what problem you see here in context of my
proposal. Did you see the words "append-only" in my proposal? Did you observe
how my prototype code creates an append-only set of unix names? The same would
be done with the lists of committers per PMC and keyids per committer. Thus
the files would be append-only (not in the line-based, 'echo >>' sense but in
the set-of-OpenPGP-packets sense).
Also, it is not a law of nature that each project shall have exactly one KEYS
file for all their releases, current and historical. It's simply a system that
somebody wrote up fifteen years ago, and it has its bugs. Just to illustrate
how arbitrary the current system is, why shouldn't there be a convention that
foo.tar.gz be accompanied by foo.tar.gz.keys? That file would be created as
a symlink to some file that contains all the right keys. Each PMC could have,
say, one KEYS file per year, and each release's .keys symlink would target the
appropriate KEYS file.
> KEYS will grow and grow.
No, they won't. /keys/group/foo.asc and /dist/release/foo/KEYS contain the same data.
> Also I am wary about allowing a bot to update the KEYS file.
> The provenance of the data is not nearly so easy to establish.
The PGP security model does not require public keys to be transported over an
authenticated channel.
Daniel
Re: Link to KEYS file on our download page
Posted by sebb <se...@gmail.com>.
On Wed, 13 Mar 2019 at 15:15, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>
> [ removing dev@svn, adding dev@whimsy — sorry if that's not the right list. ]
>
> Sebb,
>
> KEYS formats have multiple problems. They are a custom format that
> needs to be updated by hand, and if someone is a committer on N projects
> then he needs to do O(N) work to update their keys. That's a very poor design
> from a human factors point of view.
They only need to add their key on projects where they have signed a release.
That is a much smaller number.
> p.a.o/keys/ was invented to solve these problems. If it has downsides,
> fine, but don't throw the baby out with the bathwater.
>
> It would be better to change the p.a.o/keys/ cron job (1) to work, not
> off of LDAP but off of an append-only dataset mapping PMCs to committers
> and committers to keys; and (2) instead of publishing the results on
> minotaur, to auto-commit them to /repos/dist/$PMC/release/KEYS.
I think that will cause problems.
KEYS are used for archives validation as well.
Entries should not be deleted if they have ever been used to sign a release.
KEYS will grow and grow.
That is not very friendly to downloaders who want to use the KEYS file.
Also I am wary about allowing a bot to update the KEYS file.
The provenance of the data is not nearly so easy to establish.
Sebb.
Re: Link to KEYS file on our download page
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
[ removing dev@svn, adding dev@whimsy — sorry if that's not the right list. ]
Sebb,
KEYS formats have multiple problems. They are a custom format that
needs to be updated by hand, and if someone is a committer on N projects
then he needs to do O(N) work to update their keys. That's a very poor design
from a human factors point of view.
p.a.o/keys/ was invented to solve these problems. If it has downsides,
fine, but don't throw the baby out with the bathwater.
It would be better to change the p.a.o/keys/ cron job (1) to work, not
off of LDAP but off of an append-only dataset mapping PMCs to committers
and committers to keys; and (2) instead of publishing the results on
minotaur, to auto-commit them to /repos/dist/$PMC/release/KEYS.
To be clear, what I mean is something along the lines of:
[[[
# runnable prototype
HEAD=`svn info --show-item=revision $URL/to/pmcs.txt`
{ svn cat $URL/to/pmcs.txt@${HEAD} && ldapsearch -xLLL -b ou=pmc,ou=committees,ou=groups,dc=apache,dc=org cn | sed -ne 's/^cn: //p'; } | sort | uniq | svnmucc -m "Automatically regenerated by $0" -r "${HEAD}" put /dev/stdin $URL/to/pmcs.txt
]]]
Do that, do the same for the set of committers of each PMC, make the
site generation scripts use this as the input instead of LDAP, make them
commit /keys/group/foo.pmc to /dist/release/foo/KEYS, profit.
Daniel
P.S. The output of that ldapsearch is sorted by length first and
alphabetically second. Odd…
Julian Foad wrote on Tue, 12 Mar 2019 16:34 +00:00:
> Hello, devs. Apparently our handling of the KEYS file needs to change:
> see below.
>
> Is anybody willing to handle this?
>
> ----- Original message -----
> From: announce-owner@apache.org
> Subject: Returned post for announce@apache.org
>
> Sorry, but the download page is missing a required link to the KEYS file.
> The URL must be of the form: https://www.apache.org/dist/<project>/KEYS
>
> Links to http://people.apache.org/ are not acceptable; see the note here:
> https://people.apache.org/keys/
>
> Please resubmit the announce email when this has been corrected.
> Thanks,
>
> Sebb
>
> Attachments:
> * Email.eml
Re: Link to KEYS file on our download page
Posted by Julian Foad <ju...@apache.org>.
Julian Foad wrote on 2019-09-30:
> Julian Foad wrote on 2019-03-13:
>> Daniel Shahaf wrote:
>>> I replied on dev@whimsical arguing that an ASF-wide mechanism should be
>>> put in place for automatically generating KEYS files meeting the
>>> requirements stated on the referenced page and suggesting an
>>> implementation.
>>
>> Thanks! Sounds good. For anyone wanting to read or follow, that reply
>> is at:
>> https://lists.apache.org/thread.html/44164aa23523861a8f5b516de791a15f10846bc2aec8620732c481c8@%3Cdev.whimsical.apache.org%3E
>>
>>> In the meantime, if those alleged requirements are actually Foundation
>>> policy then we should manually copy /keys/group/subversion.asc to
>>> /dist/release/KEYS.
>>
>> Let's see if we can get traction on your proposal.
>
> Nothing happened there.
>
> I have now manually added a copy
> of https://people.apache.org/keys/group/subversion.asc
> to https://www.apache.org/dist/subversion/KEYS
> via https://dist.apache.org/repos/dist/release/subversion/KEYS (r36130)
> and updated our download page to point to it (r1867780).
Daniel has now committed http://svn.apache.org/r1869135 ,
"Automatically add to dist/ a current KEYS file with each release."
I am putting this in place just in time for 1.13.0.
The 1.13.0 downloads table on
http://subversion-staging.apache.org/download.cgi#recommended-release
now includes links to
https://www.apache.org/dist/subversion/subversion-1.13.0.KEYS
- Julian
Re: Link to KEYS file on our download page
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Daniel Shahaf wrote on Mon, Sep 30, 2019 at 17:00:23 +0000:
> Julian Foad wrote on Mon, 30 Sep 2019 16:34 +00:00:
> > Nothing happened there.
> >
> > I have now manually added a copy
> > of https://people.apache.org/keys/group/subversion.asc
> > to https://www.apache.org/dist/subversion/KEYS
> > via https://dist.apache.org/repos/dist/release/subversion/KEYS (r36130)
> > and updated our download page to point to it (r1867780).
>
> Thanks.
>
> However, I still wonder why we shouldn't have this command run automatically —
> .
> curl -sSf https://people.apache.org/keys/group/subversion.asc | svnmucc -U https://dist.apache.org/repos/dist/ put /dev/stdin dev/subversion/subversion-1.13.0-rc1.KEYS
> .
> — and be done with it for good. It could be run from release.py, for example.
I think the following should do it, though we may want to ask Infra to add
a «*.KEYS» pattern to their rsyncd.conf exclude= line, to prevent the *.KEYS
files from being mirrored. (That's already true for *.asc files.)
[[[
release.py: Automatically add to dist/ a current KEYS file with each release.
In particular, this means versioned KEYS files will be archived to
archive.a.o/dist/, and will continue to contain keys after those have
been removed from a committer's id.a.o profile.
* tools/dist/release.py
(download_file): Make checksum verification opt-outable.
(roll_tarballs): Download the KEYS file to the target directory.
Rely on TLS for authenticity and integrity of the downloaded
file (as we already do for authenticity and integrity of the subsequent
commit operation).
* tools/dist/templates/download.ezt,
* tools/dist/templates/rc-release-ann.ezt,
* tools/dist/templates/stable-release-ann.ezt:
Link to the per-release KEYS file.
]]]
[[[
Index: tools/dist/release.py
===================================================================
--- tools/dist/release.py (revision 1867888)
+++ tools/dist/release.py (working copy)
@@ -294,7 +294,14 @@ def run_script(verbose, script, hide_stderr=False)
for l in script.split('\n'):
run_command(l.split(), verbose, hide_stderr)
-def download_file(url, target, checksum):
+def download_file(url, target, checksum):
+ """Download the file at URL to the local path TARGET.
+ If CHECKSUM is a string, verify the checksum of the downloaded
+ file and raise RuntimeError if it does not match. If CHECKSUM
+ is None, do not verify the downloaded file.
+ """
+ assert checksum is None or isinstance(checksum, str)
+
response = urllib2.urlopen(url)
target_file = open(target, 'w+')
target_file.write(response.read())
@@ -303,7 +310,7 @@ def run_script(verbose, script, hide_stderr=False)
m.update(target_file.read())
target_file.close()
checksum2 = m.hexdigest()
- if checksum != checksum2:
+ if checksum is not None and checksum != checksum2:
raise RuntimeError("Checksum mismatch for '%s': "\
"downloaded: '%s'; expected: '%s'" % \
(target, checksum, checksum2))
@@ -966,7 +973,12 @@ def roll_tarballs(args):
shutil.copy(os.path.join(get_workdir(args.base_dir),
'subversion', 'include', 'svn_version.h'),
os.path.join(get_target(args),
- 'svn_version.h.dist-%s' % str(args.version)))
+ 'svn_version.h.dist-%s'
+ % (str(args.version),)))
+ download_file(KEYS,
+ os.path.join(get_target(args),
+ 'subversion-%s.KEYS' % (str(args.version),)),
+ None)
# And we're done!
Index: tools/dist/templates/download.ezt
===================================================================
--- tools/dist/templates/download.ezt (revision 1867888)
+++ tools/dist/templates/download.ezt (working copy)
@@ -4,10 +4,12 @@
<th>File</th>
<th>Checksum (SHA512)</th>
<th>Signatures</th>
+ <th>PGP Public Keys</th>
</tr>
[for fileinfo]<tr>
<td><a href="[[]preferred]subversion/[fileinfo.filename]">[fileinfo.filename]</a></td>
<td>[<a href="https://www.apache.org/dist/subversion/[fileinfo.filename].sha512">SHA-512</a>]</td>
- <td>[<a href="https://www.apache.org/dist/subversion/[fileinfo.filename].asc">PGP</a>]</td>
+ <td>[<a href="https://www.apache.org/dist/subversion/[fileinfo.filename].asc">PGP signatures</a>]</td>
+ <td>[<a href="https://www.apache.org/dist/subversion/subversion-[version].KEYS">PGP keyring</a>]</td>
</tr>[end]
</table>
Index: tools/dist/templates/rc-release-ann.ezt
===================================================================
--- tools/dist/templates/rc-release-ann.ezt (revision 1867888)
+++ tools/dist/templates/rc-release-ann.ezt (working copy)
@@ -23,6 +23,10 @@ PGP Signatures are available at:
For this release, the following people have provided PGP signatures:
[siginfo]
+These public keys are available at:
+
+ https://www.apache.org/dist/subversion/subversion-[version].KEYS
+
This is a pre-release for what will eventually become version [major-minor-patch] of the
Apache Subversion open source version control system. It may contain known
issues, a complete list of [major-minor-patch]-blocking issues can be found
Index: tools/dist/templates/stable-release-ann.ezt
===================================================================
--- tools/dist/templates/stable-release-ann.ezt (revision 1867888)
+++ tools/dist/templates/stable-release-ann.ezt (working copy)
@@ -34,6 +34,10 @@ PGP Signatures are available at:
For this release, the following people have provided PGP signatures:
[siginfo]
+These public keys are available at:
+
+ https://www.apache.org/dist/subversion/subversion-[version].KEYS
+
Release notes for the [major-minor].x release series may be found at:
https://subversion.apache.org/docs/release-notes/[major-minor].html
]]]
Cheers,
Daniel
Re: Link to KEYS file on our download page
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Julian Foad wrote on Mon, 30 Sep 2019 16:34 +00:00:
> Nothing happened there.
>
> I have now manually added a copy
> of https://people.apache.org/keys/group/subversion.asc
> to https://www.apache.org/dist/subversion/KEYS
> via https://dist.apache.org/repos/dist/release/subversion/KEYS (r36130)
> and updated our download page to point to it (r1867780).
Thanks.
However, I still wonder why we shouldn't have this command run automatically —
.
curl -sSf https://people.apache.org/keys/group/subversion.asc | svnmucc -U https://dist.apache.org/repos/dist/ put /dev/stdin dev/subversion/subversion-1.13.0-rc1.KEYS
.
— and be done with it for good. It could be run from release.py, for example.
Re: Link to KEYS file on our download page
Posted by Nathan Hartman <ha...@gmail.com>.
On Wed, Oct 2, 2019 at 1:32 PM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Nathan Hartman wrote on Wed, 02 Oct 2019 15:41 +00:00:
> > If there's anything else I need to do, please let me know.
>
> For bonus points, get your key cross-signed and linked to the web of trust :)
Agreed. I am keeping an eye out for key signing opportunities...
Re: Link to KEYS file on our download page
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Nathan Hartman wrote on Wed, 02 Oct 2019 15:41 +00:00:
> Nathan Hartman wrote:
> > The ASF committer keys list (https://people.apache.org/keys/committer/)
> > is showing my key as "key not found." Not really sure what to do about
> > that.
>
> I checked again and my key is found now. :-)
I can retrieve it too (two successes out of two attempts).
> > Also, some ASF help page (that I can't seem to locate now) said I need
> > to add my key to a KEYS file. Not sure where that is.
>
> Well this answers that question!
>
> If there's anything else I need to do, please let me know.
For bonus points, get your key cross-signed and linked to the web of trust :)
Cheers,
Daniel
Re: Link to KEYS file on our download page
Posted by Nathan Hartman <ha...@gmail.com>.
Nathan Hartman wrote:
> The ASF committer keys list (https://people.apache.org/keys/committer/)
> is showing my key as "key not found." Not really sure what to do about
> that.
I checked again and my key is found now. :-)
> Also, some ASF help page (that I can't seem to locate now) said I need
> to add my key to a KEYS file. Not sure where that is.
Well this answers that question!
If there's anything else I need to do, please let me know.
Re: Link to KEYS file on our download page
Posted by Julian Foad <ju...@apache.org>.
Julian Foad wrote on 2019-03-13:
> Daniel Shahaf wrote:
>> I replied on dev@whimsical arguing that an ASF-wide mechanism should be
>> put in place for automatically generating KEYS files meeting the
>> requirements stated on the referenced page and suggesting an implementation.
>
> Thanks! Sounds good. For anyone wanting to read or follow, that reply is at:
> https://lists.apache.org/thread.html/44164aa23523861a8f5b516de791a15f10846bc2aec8620732c481c8@%3Cdev.whimsical.apache.org%3E
>
>> In the meantime, if those alleged requirements are actually Foundation
>> policy then we should manually copy /keys/group/subversion.asc to
>> /dist/release/KEYS.
>
> Let's see if we can get traction on your proposal.
Nothing happened there.
I have now manually added a copy
of https://people.apache.org/keys/group/subversion.asc
to https://www.apache.org/dist/subversion/KEYS
via https://dist.apache.org/repos/dist/release/subversion/KEYS (r36130)
and updated our download page to point to it (r1867780).
- Julian
Re: Link to KEYS file on our download page
Posted by Julian Foad <ju...@apache.org>.
Daniel Shahaf wrote:
> I replied on dev@whimsical arguing that an ASF-wide mechanism should be
> put in place for automatically generating KEYS files meeting the
> requirements stated on the referenced page and suggesting an implementation.
Thanks! Sounds good. For anyone wanting to read or follow, that reply is at:
https://lists.apache.org/thread.html/44164aa23523861a8f5b516de791a15f10846bc2aec8620732c481c8@%3Cdev.whimsical.apache.org%3E
> In the meantime, if those alleged requirements are actually Foundation
> policy then we should manually copy /keys/group/subversion.asc to
> /dist/release/KEYS.
Let's see if we can get traction on your proposal.
--
- Julian
Re: Link to KEYS file on our download page
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Julian Foad wrote on Tue, 12 Mar 2019 16:34 +00:00:
> Hello, devs. Apparently our handling of the KEYS file needs to change:
> see below.
>
> Is anybody willing to handle this?
I replied on dev@whimsical arguing that an ASF-wide mechanism should be
put in place for automatically generating KEYS files meeting the
requirements stated on the referenced page and suggesting an implementation.
In the meantime, if those alleged requirements are actually Foundation
policy then we should manually copy /keys/group/subversion.asc to
/dist/release/KEYS.
Cheers,
Daniel
> - Julian
>
>
> ----- Original message -----
> From: announce-owner@apache.org
> Subject: Returned post for announce@apache.org
>
> Sorry, but the download page is missing a required link to the KEYS file.
> The URL must be of the form: https://www.apache.org/dist/<project>/KEYS
>
> Links to http://people.apache.org/ are not acceptable; see the note here:
> https://people.apache.org/keys/
>
> Please resubmit the announce email when this has been corrected.
> Thanks,
>
> Sebb
>
> Attachments:
> * Email.eml