You are viewing a plain text version of this content. The canonical link for it is here.
Posted to repository@apache.org by Henri Yandell <fl...@gmail.com> on 2006/03/01 08:59:21 UTC
Summary
Things seem quite quiet here. This is what I understand by reading the
various emails and wiki pages (Brett/Robert); and hassling Brett
mercilessly on IRC (sorry Brett):
There are four repositories:
/www/www.apache.org/dist/java-repository - ibiblio-sync m1 repo
/www/www.apache.org/dist/maven-repository - ibiblio sync m2 repo
/www/cvs.apache.org/dist/maven-snapshot-repository - snapshot m2 repo
/www/cvs.apache.org/dist/repository - snapshot m1 repo
The aim being to kill the m1 repo's and replace them with the m2
repo's at some point soon.
There are various rules:
* jars must be: md5'd, sha1'd, pgp (.asc'd).
* only asf artifacts should be present
* SNAPSHOTs must not appear in the ibiblio-sync repos
* md5 files have a specified format
There are various issues:
* unknown releases have been done (velocity-dvsl)
* jars have been overwritten (commons-cli)
* unknown projects have been released (commons-grafolia?
commons-jdbc2pool? magicGball?)
* oversight is therefore non-existent
* structure is sloppy in the m1 repos (tbh, it's sloppy in the m2 repos too)
* non-asf artifacts are there
There's history:
* This list was created with lofty goals - and various build system
involvement to create a repository structure of use to as many people
as possible (the success of the maven repository having driven a
desire to include all and not just maven)
* Now it's really just a place for managing the maven repository -
which the three main build systems in Java can all easily use (ant,
maven1, maven2)
* The wiki is mostly a result of the former character; mostly water
under the bridge now.
There's a plan for needed docs from Brett:
We need:
- how to upload releases to the repository manually (ant users, etc)
- how to automate with Maven 1.x
- how to automate with Maven 2.x
There's docs from Robert:
http://wiki.apache.org/asfrepository/RobertBurrellDonkin/MavenDocumentation
Reading the old emails; I appear to be a terrible release manager who
has caused much pain. :)
-----
I presume I've missed lots?
------
Here's some thoughts:
* The repository needs to be sliced into TLP structure. Things will
move when TLPs move; user's will have to deal. Authentication needs to
be in place so that TLPs have access only to their part of the
structure - this will do a good job of lessening the ability to push
out non-asf things.
* We need to be monitoring things as they get added. Ideally, an email
to repository@ whenever a file is added. Bigger emails when a file is
changed.
* We need to enforce that the correct amount of files are added.
Personally I think we should be enforcing that src and javadoc are
also added; along with the jar, pom and various auth files.
* We should be prepared for user accounts to the machine to go away.
* PMCs have to be responsible for deploys - snapshot or full. We
absolutely have to know who added what.
* The m2 repo needs cleaning ASAP (why is there anything in those two
repos top dirs except 'org'? We then need to be very firm on keeping
it clean and migrate the relevant parts of the m1 repo across - or
maybe ask the pmcs to do so. Finally we need to rm -r the m1 repo.
* We might want to have repository@ members performing reviews on new additions.
[* I believe SVN can give us much of this for little cost ]
Hen
Re: Summary
Posted by Steve Loughran <st...@gmail.com>.
On 3/1/06, Henri Yandell <fl...@gmail.com> wrote:
> Things seem quite quiet here. This is what I understand by reading the
> various emails and wiki pages (Brett/Robert); and hassling Brett
> mercilessly on IRC (sorry Brett):
>
>
> There are four repositories:
>
> /www/www.apache.org/dist/java-repository - ibiblio-sync m1 repo
> /www/www.apache.org/dist/maven-repository - ibiblio sync m2 repo
> /www/cvs.apache.org/dist/maven-snapshot-repository - snapshot m2 repo
> /www/cvs.apache.org/dist/repository - snapshot m1 repo
>
> The aim being to kill the m1 repo's and replace them with the m2
> repo's at some point soon.
+1
I didnt know about the m2 repo on cvs.apache.org; does it still have
everything of the m1 repository; it looks fairly sparse compared to
the m1 repo
http://cvs.apache.org/maven-snapshot-repository/
vs
http://cvs.apache.org/repository/
the latter includes 3rd party things like jena, which is part of the
problem. But maybe maven users want to use snapshots of non-apache
stuff; it needs a place too, somewhere.
> There are various rules:
>
> * jars must be: md5'd, sha1'd, pgp (.asc'd).
+1 to the PGP; I see you have been hassling people there. We have to
make sure that the pgp key works with bouncycastle for future options.
I think it may be useful to have a signatory
thirdparty-not-apache-trusted for signing 3rd party stuff, so that you
can choose whether or not to trust the third party stuff, but still
have tamper-resistance in the system.
> * only asf artifacts should be present
OK, though somewhere is needed for third party things. Sourceforge?
> * SNAPSHOTs must not appear in the ibiblio-sync repos
> * md5 files have a specified format
>
> There are various issues:
>
> * unknown releases have been done (velocity-dvsl)
> * jars have been overwritten (commons-cli)
> * unknown projects have been released (commons-grafolia?
> commons-jdbc2pool? magicGball?)
> * oversight is therefore non-existent
> * structure is sloppy in the m1 repos (tbh, it's sloppy in the m2 repos too)
> * non-asf artifacts are there
>
> There's history:
>
> * This list was created with lofty goals - and various build system
> involvement to create a repository structure of use to as many people
> as possible (the success of the maven repository having driven a
> desire to include all and not just maven)
> * Now it's really just a place for managing the maven repository -
> which the three main build systems in Java can all easily use (ant,
> maven1, maven2)
> * The wiki is mostly a result of the former character; mostly water
> under the bridge now.
>
> There's a plan for needed docs from Brett:
>
> We need:
>
> - how to upload releases to the repository manually (ant users, etc)
Ant should be automated too. If it aint, we've failed. I'd expect a
.pl or .py script for unix people too. Distribution is far too
important to do by hand.
> Here's some thoughts:
>
> * The repository needs to be sliced into TLP structure. Things will
> move when TLPs move; user's will have to deal. Authentication needs to
> be in place so that TLPs have access only to their part of the
> structure - this will do a good job of lessening the ability to push
> out non-asf things.
>
> * We need to be monitoring things as they get added. Ideally, an email
> to repository@ whenever a file is added. Bigger emails when a file is
> changed.
yes. state monitoring is good. an RSS feed too ?
> * We need to enforce that the correct amount of files are added.
> Personally I think we should be enforcing that src and javadoc are
> also added; along with the jar, pom and various auth files.
+1
> * The m2 repo needs cleaning ASAP (why is there anything in those two
> repos top dirs except 'org'? We then need to be very firm on keeping
> it clean and migrate the relevant parts of the m1 repo across - or
> maybe ask the pmcs to do so. Finally we need to rm -r the m1 repo.
this is trouble. I think it may already be almost too late to impose a
new structure. But if we don't, then we end up in the
scalability/management mess that we are trying to leave behind.
If it were done, then do it now: patch every pom, move every file. Be
brutal, before the migration from m1 to m2, has taken place, and
before the m2 tasks get used much in ant. And before "Java development
in Ant, 2nd edition", is code-frozen. I will take on the work
correcting that :)
The other bit of interest is on the maven dev list; glassfish includes
all the source to many of the javax.* artifacts. We cannot redist the
compiled stuff, but we are allowed to recompile and redist. so we may
have to have a repository of Apache-rebuilt-sun stuff in some location
(org.apache.javax?)
-steve
Re: Summary
Posted by Dain Sundstrom <da...@iq80.com>.
On Mar 4, 2006, at 2:04 PM, Steve Loughran wrote:
> On 3/4/06, Henri Yandell <fl...@gmail.com> wrote:
>> On 3/3/06, Dain Sundstrom <da...@iq80.com> wrote:
>>>
>>> BTW it would be nice if we could just use standard Java Jar signing.
>>> That way the ultimate user of the code, the JVM, can verify the Jar.
>>
>> Hearing this idea a lot; Steve Loughran had some emails saying that
>> signing wouldn't work - Steve?
>>
>> Hen
>>
>
> It would be nice, cos then java webstart could run from the
> repository. But once a jar is signed, only jars signed by the same
> person can declare classes/resources in the same package (I think the
> root package is special, as in META-INF)
>
> As a consequence
> -hibernate breaks; it cannot add new proxy classes for your code
> on the fly
> -nobody would be allowed to add new classes to the package in any
> other JAR
Package Sealing is an optional flag in the Jar manifest (http://
java.sun.com/j2se/1.4.2/docs/guide/extensions/spec.html). If you
simply don't include include the "Sealed: true" entry in the manifest
or specifically set it to "Sealed: false" and you won't get sealing.
Further, sealing is implemented by the classloader itself. The
UrlClassLoader respects the entry, but others may or may not. For
example, webstart below always turns on Sealing when dealing with a
signed application.
> problem #2 kind of goes against your right of an OSS user, the easy
> ability to add new stuff to a JAR. So, say I wanted to patch
> ant-junit.jar, which declares stuff in org.apache.tools.ant.optional,
> I'd need to rebuild the whole of ant or strip out the signatures, just
> to get my signal jar to work. Which complicates redist too.
>
> Now, if you design an app with signing in from the outset, maybe this
> would be a feature not a problem. So, say maven could always only
> download and run signed plugins; it would be signed itself from the
> outset, so as long as that original bootstrapper got to you securely,
> and all instructions it received were authenticated, you would have a
> local chain of trust.
I agree, so if it isn't possible to turn off Sealing then this will
not work.
> And returning to webstart, Its flawed, horribly, I just havent sat
> down to prove it yet. When you run a webstart app an HTML doc is
> downloaded that lists the JARs to run, the JRE pulls them down and
> runs them, starting at the main entry point listed in the descriptor.
> If a signed JAR has any other entry point in, then it is at risk of
> being called. Does anyone audit their JARs for entry points? Exactly.
> If you sign a JAR you are saying "safe to use in a java web start
> triggered by an untrusted HTML descriptor", which is not something we
> are prepared to say.
Signing is supposed to only assure that you know who signed the file
and that the file hasn't been tapered with. Signing the file doesn't
say that the file is usable for any purpose. Further java webstart
has a very very restrictive set of signing rules:
An application launched by a JNLP Client is considered to be signed,
if and only if:
o All the JAR files are signed (both for jar and nativelib elements)
and can be verified. A JAR file is signed if all the entries
(excluding manifest entries, the signature iteself, and empty
directories) are signed by a single signature.
o If a signed version of the JNLP file exists, then it must be
verified, and it must match the JNLP file used to launch the
application. This is described in the following subsection.
o The same certificate is used to sign all JAR files (jar and
nativelib elements) that are part of a single JNLP file. This
simplifies user management since only one certificate needs to be
presented to the user during a launch per JNLP file (and hardly
restricts the signing process in practice).
o The certificate used for signing the JAR files and JNLP file (if
signed) must be verified against a set of trusted root certificates.
Further for an application to be run in a trusted environment
(normally webstart application run in an applet like environemnt),
the spec states:
The following requirements must be satisfied before a JNLP Client can
grant an application these access rights:
o The application is signed.
o The user and/or the JNLP Client trusts the certificate that is used
to sign the application.
Anyway, I think webstart is cool, but not really important to this
discussion.
-dain
Re: Summary
Posted by Steve Loughran <st...@gmail.com>.
On 3/4/06, Henri Yandell <fl...@gmail.com> wrote:
> On 3/3/06, Dain Sundstrom <da...@iq80.com> wrote:
> >
> > BTW it would be nice if we could just use standard Java Jar signing.
> > That way the ultimate user of the code, the JVM, can verify the Jar.
>
> Hearing this idea a lot; Steve Loughran had some emails saying that
> signing wouldn't work - Steve?
>
> Hen
>
It would be nice, cos then java webstart could run from the
repository. But once a jar is signed, only jars signed by the same
person can declare classes/resources in the same package (I think the
root package is special, as in META-INF)
As a consequence
-hibernate breaks; it cannot add new proxy classes for your code on the fly
-nobody would be allowed to add new classes to the package in any other JAR
problem #2 kind of goes against your right of an OSS user, the easy
ability to add new stuff to a JAR. So, say I wanted to patch
ant-junit.jar, which declares stuff in org.apache.tools.ant.optional,
I'd need to rebuild the whole of ant or strip out the signatures, just
to get my signal jar to work. Which complicates redist too.
Now, if you design an app with signing in from the outset, maybe this
would be a feature not a problem. So, say maven could always only
download and run signed plugins; it would be signed itself from the
outset, so as long as that original bootstrapper got to you securely,
and all instructions it received were authenticated, you would have a
local chain of trust.
And returning to webstart, Its flawed, horribly, I just havent sat
down to prove it yet. When you run a webstart app an HTML doc is
downloaded that lists the JARs to run, the JRE pulls them down and
runs them, starting at the main entry point listed in the descriptor.
If a signed JAR has any other entry point in, then it is at risk of
being called. Does anyone audit their JARs for entry points? Exactly.
If you sign a JAR you are saying "safe to use in a java web start
triggered by an untrusted HTML descriptor", which is not something we
are prepared to say.
-steve
Re: Summary
Posted by Henri Yandell <fl...@gmail.com>.
On 3/3/06, Dain Sundstrom <da...@iq80.com> wrote:
> On Mar 3, 2006, at 4:00 AM, Brett Porter wrote:
>
> > On writability, my understanding is that files should be 644 and
> > directories 775, with the sections separated by TLP owned by their
> > group only.
>
> For the release repository they could be 444 (to avoid the
> possibility or accidental deletions) and 775, but for the snapshot
> repository they should be 664 and 775.
>
> >> I think that, to increase responsibility, release managers should
> >> be authorised by pmc's. That is not hard to check or implement.
> >> See my specific proposal under 'problems and solutions' in
> >>
> >> http://people.apache.org/~henkp/trust/
> >
> > Though I've read it before, I haven't thought a lot about these. These
> > look like some good solutions. This seems like an important but
> > parallel discussion, since it should effect the whole of /dist/.
Sounds good, tree of trust :) Codifying the oversight we always talk
about in something actually viewable.
>
> +1
>
> BTW it would be nice if we could just use standard Java Jar signing.
> That way the ultimate user of the code, the JVM, can verify the Jar.
Hearing this idea a lot; Steve Loughran had some emails saying that
signing wouldn't work - Steve?
Hen
Re: Summary
Posted by Dain Sundstrom <da...@iq80.com>.
On Mar 3, 2006, at 4:00 AM, Brett Porter wrote:
> On writability, my understanding is that files should be 644 and
> directories 775, with the sections separated by TLP owned by their
> group only.
For the release repository they could be 444 (to avoid the
possibility or accidental deletions) and 775, but for the snapshot
repository they should be 664 and 775.
>> I think that, to increase responsibility, release managers should
>> be authorised by pmc's. That is not hard to check or implement.
>> See my specific proposal under 'problems and solutions' in
>>
>> http://people.apache.org/~henkp/trust/
>
> Though I've read it before, I haven't thought a lot about these. These
> look like some good solutions. This seems like an important but
> parallel discussion, since it should effect the whole of /dist/.
+1
BTW it would be nice if we could just use standard Java Jar signing.
That way the ultimate user of the code, the JVM, can verify the Jar.
-dain
Re: Summary
Posted by Brett Porter <br...@gmail.com>.
On 3/3/06, Henk P. Penning <he...@cs.uu.nl> wrote:
> If the /download/ tools don't support sigs, so be it.
> The /upload/ tools must require and check sigs.
We totally agree. Let's not get diverted by this discussion, I think
we agree we need to get sigs. All I was pointing out earlier is that
Maven can use md5s (or sha1s) to verify the download is not corrupted,
so its good to store those until such time as it can deal with sigs on
download.
> To repeat, the repositories need sigs, especially because of
> the old (deplorable) habit to make files group writable.
> That implies that almost all repository files can be (over)written
> by anyone in group 'apcvs' (that is all committers, 1000+ persons)
> File ownership means nothing. We want sigs so we know who released what.
These are the current rules:
http://www.apache.org/dist/maven-repository/README.txt
On this new repository, nothing gets to ibiblio if it isn't followed,
which seems to be helping. The software is pretty much in place to
automate that step.
On writability, my understanding is that files should be 644 and
directories 775, with the sections separated by TLP owned by their
group only.
So, should we expand on those rules in any way? If not, is the next
step to set them as policy and forward it out to PMCs? I think we've
collectively said all there is to be said on the topic in the last
year. How do we get it done?
> I think that, to increase responsibility, release managers should
> be authorised by pmc's. That is not hard to check or implement.
> See my specific proposal under 'problems and solutions' in
>
> http://people.apache.org/~henkp/trust/
Though I've read it before, I haven't thought a lot about these. These
look like some good solutions. This seems like an important but
parallel discussion, since it should effect the whole of /dist/.
Thanks!
- Brett
Re: Summary
Posted by "Henk P. Penning" <he...@cs.uu.nl>.
On Fri, 3 Mar 2006, Niclas Hedhman wrote:
> Date: Fri, 3 Mar 2006 11:37:57 +0800
> From: Niclas Hedhman <ni...@hedhman.org>
> To: repository@apache.org
> Subject: Re: Summary
> Sender: hedhman@gmail.com
>
> On 3/3/06, Noel J. Bergman <no...@devtech.com> wrote:
> >
> > > I think Brett has a point. Keep the md5 and/or sha1 for simple download
> > > verification
> >
> > They are absolutely worthless if you download them from anywhere other
> > than a trusted source, which excludes mirrors.
> People, can we agree that we are talking about two different things??
Of course ; the point is that, in principle, sigs make md5's obsolete,
and md5's don't make sigs obsolete.
The ASF requires sigs ; not in two years, but now.
So, the repository support tools should support sigs.
If the /download/ tools don't support sigs, so be it.
The /upload/ tools must require and check sigs.
The current situation, where generating sigs is entirely left
to the uploader, doesn't work. Repository release managers
don't sign stuff unless invited, nagged or forced. It is
unclear which pmc is responsible for which repository releases ;
pmc's hardly see repository releases as their responsibility.
Do pmc's ever approve repository releases ? Or is the release
of 'dist/TLP/something' an implicit invitation for anyone to
put stuff in 'dist/....-repository/somewhere/somehow-something' ?
To repeat, the repositories need sigs, especially because of
the old (deplorable) habit to make files group writable.
That implies that almost all repository files can be (over)written
by anyone in group 'apcvs' (that is all committers, 1000+ persons)
File ownership means nothing. We want sigs so we know who released what.
I think that, to increase responsibility, release managers should
be authorised by pmc's. That is not hard to check or implement.
See my specific proposal under 'problems and solutions' in
http://people.apache.org/~henkp/trust/
> Niclas
HPP
---------------------------------------------------------------- _
Henk P. Penning, Computer Systems Group R Uithof CGN-A232 _/ \_
Dept of Computer Science, Utrecht University T +31 30 253 4106 / \_/ \
Padualaan 14, 3584CH Utrecht, the Netherlands F +31 30 251 3791 \_/ \_/
http://www.cs.uu.nl/staff/henkp.html M penning@cs.uu.nl \_/
Re: Summary
Posted by Niclas Hedhman <ni...@hedhman.org>.
On 3/3/06, Noel J. Bergman <no...@devtech.com> wrote:
>
> > I think Brett has a point. Keep the md5 and/or sha1 for simple download
> > verification
>
> They are absolutely worthless if you download them from anywhere other
> than
> a trusted source, which excludes mirrors.
>
> This is why Henk P. Penning is pushing for us to stop distributing MD5s,
> and
> to require users to verify downloaded files against MD5s maintained here.
> See his message
>
> http://mail-archives.apache.org/mod_mbox/www-repository/200603.mbox/%3cPine
> .
> GSO.4.44.0603020038260.7085-100000@castor.cs.uu.nl%3e
>
People, can we agree that we are talking about two different things??
One side; We need authentication of the downloaded artifacts. Essential!
The other side; We want to be able to verify that the download succeeded and
was not corrupted.
We who wants the latter, still thinks that the former is excellent, but it
will take a while, and _meanwhile_ can we keep the checksum for downloads...
Cheers
Niclas
RE: Summary
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I think Brett has a point. Keep the md5 and/or sha1 for simple download
> verification
They are absolutely worthless if you download them from anywhere other than
a trusted source, which excludes mirrors.
This is why Henk P. Penning is pushing for us to stop distributing MD5s, and
to require users to verify downloaded files against MD5s maintained here.
See his message
http://mail-archives.apache.org/mod_mbox/www-repository/200603.mbox/%3cPine.
GSO.4.44.0603020038260.7085-100000@castor.cs.uu.nl%3e
--- Noel
Re: Summary
Posted by Steve Loughran <st...@gmail.com>.
On 3/2/06, Niclas Hedhman <ni...@hedhman.org> wrote:
>
>
> On 3/2/06, Brett Porter <br...@gmail.com> wrote:
> > I understand, but that requires that you get and importa keys, which
> > is a much more sophisticated operation. All we are using the sha1 for
> > is to check that the download didn't get cut off halfway through.
> >
>
> I think Brett has a point. Keep the md5 and/or sha1 for simple download
> verification, at least for quite a while. Meanwhile, Maven folks and we who
> do those automated download tools, can start look into a pgp driven solution
> which solves both the download integrity concern as well as the security
> aspects. But I think that will take a year or two, before it has been pushed
> out and can replace the checksum...
md5 and sh1 are nice and easy to verify in java; no extra libs. pgp
needs bouncy castle.
In smartfrog, you can declare a deployment descriptor not just the
version of a lib to d/l, but its md5/sha1 checksum, which is then used
to check the integrity of the app: the deployment will fail if the
checksum is unequal.
the deploymend descriptor itself then goes into a signed jar, which
the daemon retrieves the descriptor from, verifying the signing in the
process. And the daemons only trust JAR files signed by the select few
entitities you explicitly add: there is no default. As a result, the
sha1 checksums of the redistributed artifacts are the end of the
security chain, which is about as strong as Sun's JAR signing
mechanism (which is MD5, right?)
Interestingly we dont redist Smartfrog signed, even though we could,
because then the sun classloader switches into wierd-mode, every jar
signed is inherently sealed except to other jars signed by the same
signatories, even if you dont say "sealed" in the manifest. this has
adverse consequences. For example, hibernate doesnt work properly when
trying to persist classes in signed JARs, because it tries to create
new proxy classes in the same package.
I dont understand all this security stuff; I have a colleague who
claims to, and he is sufficiently paranoid that I have to go with him.
He doesnt trust TPMs because the government may have got there first,
even though they were invented in our building, by people we know.
-steve
-Steve
Re: Summary
Posted by Niclas Hedhman <ni...@hedhman.org>.
On 3/2/06, Brett Porter <br...@gmail.com> wrote:
>
> I understand, but that requires that you get and importa keys, which
> is a much more sophisticated operation. All we are using the sha1 for
> is to check that the download didn't get cut off halfway through.
>
I think Brett has a point. Keep the md5 and/or sha1 for simple download
verification, at least for quite a while. Meanwhile, Maven folks and we who
do those automated download tools, can start look into a pgp driven solution
which solves both the download integrity concern as well as the security
aspects. But I think that will take a year or two, before it has been pushed
out and can replace the checksum...
Cheers
Niclas
Re: Summary
Posted by Brett Porter <br...@gmail.com>.
I understand, but that requires that you get and importa keys, which
is a much more sophisticated operation. All we are using the sha1 for
is to check that the download didn't get cut off halfway through.
On 3/2/06, Noel J. Bergman <no...@devtech.com> wrote:
> Brett Porter wrote:
>
> > one of [MD5,SHA1] is needed for checking download integrity (its not a
> > security mechanism at all).
>
> If I sign a file:
>
> gpg --output foo.asc --detach-sig --armor foo; done
>
> then it is signed by me, and the check:
>
> $ gpg --verify foo.asc
>
> will fail if the file is changed from what I signed. A PGP signed file can
> be verified against what the release manager claims to have signed. An MD5
> is only as good as the source for the MD5.
>
> --- Noel
>
>
Re: Summary
Posted by "Henk P. Penning" <he...@cs.uu.nl>.
On Thu, 2 Mar 2006, Brett Porter wrote:
> Date: Thu, 2 Mar 2006 10:29:31 +1100
> From: Brett Porter <br...@gmail.com>
> To: repository@apache.org
> Subject: Re: Summary
>
> I haven't reviewed the rest of the email yet, but on this point, one
> of the others is needed for checking download integrity (its not a
> security mechanism at all).
Hm, if everything is pgp signed, ASF can check that the files on
www.apache.org are ok ; The ASF keeps a database mapping md5 -> file ;
the download user computes the md5 of the downloaded file, and
ask a secure ASF server which file has the computed md5.
That's how my checker stuff works :
http://people.apache.org/~henkp/cgi-bin/md5.cgi
-- the release manager doesn't need to provide md5's, .md5's are obsolete
-- currently .md5's are rsynced by the mirrors ; that's nonsense.
> On 3/2/06, Noel J. Bergman <no...@devtech.com> wrote:
> > > * jars must be: md5'd, sha1'd, pgp (.asc'd).
> >
> > Justification? I only do PGP, nor do I see any need for anything else.
> >
> > --- Noel
HPP
---------------------------------------------------------------- _
Henk P. Penning, Computer Systems Group R Uithof CGN-A232 _/ \_
Dept of Computer Science, Utrecht University T +31 30 253 4106 / \_/ \
Padualaan 14, 3584CH Utrecht, the Netherlands F +31 30 251 3791 \_/ \_/
http://www.cs.uu.nl/staff/henkp.html M penning@cs.uu.nl \_/
RE: Summary
Posted by "Noel J. Bergman" <no...@devtech.com>.
Brett Porter wrote:
> one of [MD5,SHA1] is needed for checking download integrity (its not a
> security mechanism at all).
If I sign a file:
gpg --output foo.asc --detach-sig --armor foo; done
then it is signed by me, and the check:
$ gpg --verify foo.asc
will fail if the file is changed from what I signed. A PGP signed file can
be verified against what the release manager claims to have signed. An MD5
is only as good as the source for the MD5.
--- Noel
Re: Summary
Posted by Brett Porter <br...@gmail.com>.
I haven't reviewed the rest of the email yet, but on this point, one
of the others is needed for checking download integrity (its not a
security mechanism at all).
On 3/2/06, Noel J. Bergman <no...@devtech.com> wrote:
> > * jars must be: md5'd, sha1'd, pgp (.asc'd).
>
> Justification? I only do PGP, nor do I see any need for anything else.
>
> --- Noel
>
Re: Summary
Posted by Steve Loughran <st...@gmail.com>.
On 3/1/06, Henk P. Penning <he...@cs.uu.nl> wrote:
> On Tue, 28 Feb 2006, Henri Yandell wrote:
>
> > Date: Tue, 28 Feb 2006 23:59:21 -0800
> > From: Henri Yandell <fl...@gmail.com>
> > To: repository@apache.org
> > Subject: Summary
>
> > * jars must be: md5'd, sha1'd, pgp (.asc'd).
>
> IMHO, it's nonsense to have both md5 and sha1.
MD5 is 0wned, at least in crypto terms; SHA1 is next on the list. It
has a few years left. but md5+SHA1 is more secure. PGP best yet.
One problem all have is they just checksum the file, but in java-land,
signing a jar internally affects the file. So if I sign a file, I've
just changed its sha1 checksum. This isnt relevant for the apache
repositories, but matters in my day work, deployment, where our
runtime uses a secure classloader that only loads signed jars.
steve
-Steve
Re: Summary
Posted by Henri Yandell <fl...@gmail.com>.
On 3/1/06, Henk P. Penning <he...@cs.uu.nl> wrote:
> On Wed, 1 Mar 2006, Noel J. Bergman wrote:
>
> > Date: Wed, 1 Mar 2006 18:19:36 -0500
> > From: Noel J. Bergman <no...@devtech.com>
> > To: repository@apache.org
> > Subject: RE: Summary
> >
> > > * jars must be: md5'd, sha1'd, pgp (.asc'd).
> >
> > Justification? I only do PGP, nor do I see any need for anything else.
>
> Fine, great. Much better to concentrate on one mechanism,
> and strive for perfection. I'm pushing this agenda:
>
> -- every committer must have a pgp key in ~user/.pgpkey
> -- every release manager must be in the (apache) strong set
>
> Every new committer should be asked for a pgp key ;
> new-user script checks if the pubkey is on the keyservers ;
> puts user pubkey in ~user/.pgpkey ; emails initial password
> pgp encrypted to new user.
The irritating part with this agenda is that PGP is hugely the most
painful part of doing a release - and it locks out people who haven't
joined the clique of 'who-has-signed-who'. I'm still building up the
energy to figure out how to move my PGP key from minotaur to somewhere
off minotaur (after being told not to use minotaur) - partly due to
effort involved in grokking all this, but mostly due to not having
anywhere I trust more than minotaur.
It bemuses me that PGP has been such a pain to me, but it is the
single most reason why I've not done a release in the last couple of
years.
I understand and accept the reasoning though. We can't have a single
PGP key for Apache as that would be too juicy a target to attack
(right?), we can't trust SVN credentials as they are too easy to break
(especially as they're plain text on the client), Asylum isn't
available yet and might not be any easier than the PGP stuff anyway.
As to the pain of needing three types of authentication on files (md5,
sha1, pgp) - I agree. Anything we can do to make the technical aspect
of releasing simpler is good.
Hen
RE: Summary
Posted by "Henk P. Penning" <he...@cs.uu.nl>.
On Wed, 1 Mar 2006, Noel J. Bergman wrote:
> Date: Wed, 1 Mar 2006 18:19:36 -0500
> From: Noel J. Bergman <no...@devtech.com>
> To: repository@apache.org
> Subject: RE: Summary
>
> > * jars must be: md5'd, sha1'd, pgp (.asc'd).
>
> Justification? I only do PGP, nor do I see any need for anything else.
Fine, great. Much better to concentrate on one mechanism,
and strive for perfection. I'm pushing this agenda:
-- every committer must have a pgp key in ~user/.pgpkey
-- every release manager must be in the (apache) strong set
Every new committer should be asked for a pgp key ;
new-user script checks if the pubkey is on the keyservers ;
puts user pubkey in ~user/.pgpkey ; emails initial password
pgp encrypted to new user.
Do you know where the CLA/new-user scripts live ?
> --- Noel
HPP
---------------------------------------------------------------- _
Henk P. Penning, Computer Systems Group R Uithof CGN-A232 _/ \_
Dept of Computer Science, Utrecht University T +31 30 253 4106 / \_/ \
Padualaan 14, 3584CH Utrecht, the Netherlands F +31 30 251 3791 \_/ \_/
http://www.cs.uu.nl/staff/henkp.html M penning@cs.uu.nl \_/
RE: Summary
Posted by "Noel J. Bergman" <no...@devtech.com>.
> * jars must be: md5'd, sha1'd, pgp (.asc'd).
Justification? I only do PGP, nor do I see any need for anything else.
--- Noel
Re: Summary
Posted by "Henk P. Penning" <he...@cs.uu.nl>.
On Tue, 28 Feb 2006, Henri Yandell wrote:
> Date: Tue, 28 Feb 2006 23:59:21 -0800
> From: Henri Yandell <fl...@gmail.com>
> To: repository@apache.org
> Subject: Summary
> * jars must be: md5'd, sha1'd, pgp (.asc'd).
IMHO, it's nonsense to have both md5 and sha1.
-- it is very easy to generate the sha's, but who is
going to check them for consistency? (I'm not :-).
-- according to the [draft] policy, sha's should be in '.sha'
http://www.apache.org/dev/release-signing.html
Regarding ibiblio: if I remember correctly, ibiblio doesn't want
to delete stuff ; wasn't that a requirement for their involvement?
> Hen
HPP
---------------------------------------------------------------- _
Henk P. Penning, Computer Systems Group R Uithof CGN-A232 _/ \_
Dept of Computer Science, Utrecht University T +31 30 253 4106 / \_/ \
Padualaan 14, 3584CH Utrecht, the Netherlands F +31 30 251 3791 \_/ \_/
http://www.cs.uu.nl/staff/henkp.html M penning@cs.uu.nl \_/