You are viewing a plain text version of this content. The canonical link for it is here.
Posted to repository@apache.org by Stefano Bagnara <ap...@bago.org> on 2006/09/17 03:04:12 UTC
maven2 based releases for the james project and ASF policy
Hi all,
I know there is an ongoing thread about ASF/maven2 repositories and
third party library, but it seems to me that we won't have an ASF-wide
solution in few weeks, am I right?
We (Apache James project) have two "new" products based on maven2 that
are ready to be released: jSPF and Mime4J.
Both projects depends on third party (license compatible) jars and our
snapshots currently depends on a maven repository I set up in my
minotaur home to be able to build the projects.
Of course this is no good because we can't publish official releases
including references to my home or including references to SNAPSHOT
projects.
One of James PMC members is concerned (and we, other PMC member, agree
on his concerns) about the security issues introduced by downloading
artifacts from ibiblio or its mirrors, so we are trying to find an
interim solution while ASF define a common way.
Here is what I've proposed:
1) create a "repository/third-party-m1" folder in our
svn.apache.org/repos/asf/james repository.
2) commit there our current third party dependencies (BSD/CDDL/MIT/ASF)
3) export the content of this repository on a subfolder of our
james.apache.org website (james.apache.org/repos/third-party-m1 could be
a good candidate) so that we don't link directly the SVN server but a
mirrored resource (websites are mirrored, right?)
4) add this "james.apache.org/repos/third-party-m1" to our main pom
(overwriting ibiblio).
We would still use the 2 ASF-wide maven repositories to publish our
official release or to read ASF jars and for our snapshots needs.
Does ASF policy allow us to do this? WDYT?
Stefano
Re: maven2 based releases for the james project and ASF policy
Posted by Brett Porter <br...@gmail.com>.
I'll say 3 - 6 months - it depends on when we can get started, and
also when that release is generally available. Could be sooner.
- Brett
On 19/09/06, Stefano Bagnara <ap...@bago.org> wrote:
> Hi Brett,
>
> I read your proposal maybe more than 1 month ago, and it seems very good
> to me.
>
> IIRC this is something still being discussed and there is no real
> roadmap (no developer to be assigned) for it to be included in the next
> maven 2.1 release: is this correct?
>
> Otherwise, can you give an ETA for this stuff? I don't want to hurry
> you, I just would like to have an estimate time (1 month? 3 months? 1
> year?) so that we can take it into consideration while discussing
> alternative interim solutions.
>
> I CC general@james.apache.org (where Noel was discussing with us about
> this topic, before I moved to repository@ to find further suggestions)
> so we've much more probability Noel is listening.
>
> Stefano
>
> Brett Porter wrote:
> > On 17/09/06, Stefano Bagnara <ap...@bago.org> wrote:
> >> One of James PMC members is concerned (and we, other PMC member, agree
> >> on his concerns) about the security issues introduced by downloading
> >> artifacts from ibiblio or its mirrors, so we are trying to find an
> >> interim solution while ASF define a common way.
> >
> > BTW, as I'm sure Noel is listening - I'm still waiting on his feedback
> > to the proposal I put up specifically about his concerns.
> >
> > http://docs.codehaus.org/display/MAVEN/Repository+Security+Improvements
> >
> > On this thread, one gotcha I'll note about using file:/ repositories -
> > it may be difficult to get them to work as expected in a multiple
> > module project. They can still work, it just requires redefining them
> > in all POMs that use it, you can't inherit it with the correct
> > directory settings.
> >
> > Thanks,
> > Brett
> >>
> >> Here is what I've proposed:
> >>
> >> 1) create a "repository/third-party-m1" folder in our
> >> svn.apache.org/repos/asf/james repository.
> >>
> >> 2) commit there our current third party dependencies (BSD/CDDL/MIT/ASF)
> >>
> >> 3) export the content of this repository on a subfolder of our
> >> james.apache.org website (james.apache.org/repos/third-party-m1 could be
> >> a good candidate) so that we don't link directly the SVN server but a
> >> mirrored resource (websites are mirrored, right?)
> >>
> >> 4) add this "james.apache.org/repos/third-party-m1" to our main pom
> >> (overwriting ibiblio).
> >>
> >>
> >> We would still use the 2 ASF-wide maven repositories to publish our
> >> official release or to read ASF jars and for our snapshots needs.
> >>
> >>
> >> Does ASF policy allow us to do this? WDYT?
> >>
> >> Stefano
>
>
>
--
Apache Maven - http://maven.apache.org
"Better Builds with Maven" book - http://library.mergere.com/
Re: maven2 based releases for the james project and ASF policy
Posted by Stefano Bagnara <ap...@bago.org>.
Hi Brett,
I read your proposal maybe more than 1 month ago, and it seems very good
to me.
IIRC this is something still being discussed and there is no real
roadmap (no developer to be assigned) for it to be included in the next
maven 2.1 release: is this correct?
Otherwise, can you give an ETA for this stuff? I don't want to hurry
you, I just would like to have an estimate time (1 month? 3 months? 1
year?) so that we can take it into consideration while discussing
alternative interim solutions.
I CC general@james.apache.org (where Noel was discussing with us about
this topic, before I moved to repository@ to find further suggestions)
so we've much more probability Noel is listening.
Stefano
Brett Porter wrote:
> On 17/09/06, Stefano Bagnara <ap...@bago.org> wrote:
>> One of James PMC members is concerned (and we, other PMC member, agree
>> on his concerns) about the security issues introduced by downloading
>> artifacts from ibiblio or its mirrors, so we are trying to find an
>> interim solution while ASF define a common way.
>
> BTW, as I'm sure Noel is listening - I'm still waiting on his feedback
> to the proposal I put up specifically about his concerns.
>
> http://docs.codehaus.org/display/MAVEN/Repository+Security+Improvements
>
> On this thread, one gotcha I'll note about using file:/ repositories -
> it may be difficult to get them to work as expected in a multiple
> module project. They can still work, it just requires redefining them
> in all POMs that use it, you can't inherit it with the correct
> directory settings.
>
> Thanks,
> Brett
>>
>> Here is what I've proposed:
>>
>> 1) create a "repository/third-party-m1" folder in our
>> svn.apache.org/repos/asf/james repository.
>>
>> 2) commit there our current third party dependencies (BSD/CDDL/MIT/ASF)
>>
>> 3) export the content of this repository on a subfolder of our
>> james.apache.org website (james.apache.org/repos/third-party-m1 could be
>> a good candidate) so that we don't link directly the SVN server but a
>> mirrored resource (websites are mirrored, right?)
>>
>> 4) add this "james.apache.org/repos/third-party-m1" to our main pom
>> (overwriting ibiblio).
>>
>>
>> We would still use the 2 ASF-wide maven repositories to publish our
>> official release or to read ASF jars and for our snapshots needs.
>>
>>
>> Does ASF policy allow us to do this? WDYT?
>>
>> Stefano
Re: maven2 based releases for the james project and ASF policy
Posted by Steve Loughran <st...@gmail.com>.
On 25/09/06, robert burrell donkin <rd...@apache.org> wrote:
> On Mon, 2006-09-25 at 11:05 +1000, Brett Porter wrote:
> > On 23/09/2006, at 10:31 PM, robert burrell donkin wrote:
>
> <snip>
>
> > > given that the repository is secure then a checksum should be good
> > > enough and is easier for users to understand.
> >
> > I'd certainly like to start there with the options in the document.
> > So, cleaning up the checksums in the repository, making sure Maven
> > can pull them from the source repository rather than a mirror, and
> > allowing them to be hardcoded into the POM would all make for a
> > reasonable security system.
>
> in terms of a replacement attack where someone subverts a mirror, i
> would say so.
>
> AIUI both MD5 and SHA1 have been broken in a technical sense but should
> be ok from a practical perspective for the next few years. i don't think
> that we need to worry overly about this
Md5 is what RPM distro's are based from; if its owned then linux is too.
Even so, a design you start today has to think more about the
future.The big risk is that someone deliberately creates a collision
and releases the good file to the repository, while retaining the bad
file for subversion on a mirror. I dont know if zip files are easily
subverted this way.
Sha1+MD5 together is good.
>
> since we use detached signatures, if these hashing algorithms are
> considered too weak for our purposes, we would need to be very careful
> about the signing algorithms we allow and choose only algorithms which
> do not rely on these hash algorithms. we would also need to ensure that
> the key lengths were chosen carefully.
>
> digital signatures definitely provide a lot of extra security at a low
> cost but do require knowledge to interpret.
>
The biggest problem with starting to add security is the need to do
end-to-end security. right up from the moment somebody downloads it.
SSH is the best example of paranoia at work, such as the way it wont
read .ssh if the directory is world readable.
I could imagine a privilege escalation if one user kept their keys in
a directory that was group writeable, and of course there's no way to
check for this in Java (exec a shell script?). You'd add an extra
trusted key then serve up subverted artifacts under the new key. You
would have to hit the proxy settings too, perhaps, or a local mirror
site.
Realistically, I dont worry about this because most projects I've been
on use a private SCM-managed repository. Anyone running binaries from
a shared file system have implicit trust in the rest of the group. But
once you try and do security, you do have to worry about all of these
things, and be more rigorous than before
-steve
> > However, I got the indication that some people wouldn't think this
> > was sufficient.
>
> i don't think that checking checksums alone is sufficient but it is a
> start.
>
> checking checksums should be good enough for most users provided that
> the trustworthiness of the checksums can be guaranteed. it's this last
> bit which is difficult. i don't see any easy solution to this.
>
> > > it's really about the trust model.
> > >
> > > one issue is that determined attackers could easily this system if
> > > second or third had signatures are trusted transitively. mallory
> > > legitimately gets a connection to the web of trust then fakes an
> > > entire
> > > sub-graph populated by fictional characters. this would be very
> > > convincing to an automated system with only moderate risk to
> > > mallory who
> > > could claim ignorance of the scam when confronted.
> >
> > Right. I think this is best counteracted by checking both the trust
> > in the person's key, and a secondary method of associating them with
> > the project that you are checking. That's starting to make the system
> > a bit complicated though.
>
> if you know that the key is used to sign releases for that project then
> the identity of the signer is not relevant.
>
> > > multiple signatures for each release may be a good way to cheaply
> > > increase security. the release managers could sign, the maven uploader
> > > could also sign to indicate that they had verified the release
> > > managers
> > > signature. a maven auto-signer could add another signature to indicate
> > > that it had been uploaded through the official mechanism. a scoring
> > > system could be used to present this information to the user.
> >
> > This is interesting, but I worry that the complexity makes it harder
> > for the user to really answer the question of whether they trust it.
>
> a scoring system is just a simple way to present the result in a form
> which does not require a lot of knowledge. for example:
>
> * trusted autosign
> *** trusted autosign plus trusted uploader signature or trusted
> release manager
> ***** trusted autosign plus trusted uploader signature plus trusted
> release manager signature
>
> i think that most users would understand 5 star security rating better
> than the explanation the right. it's also less to read. maybe expert
> users could customise the scoring system.
>
> > I think it needs to be a simple question for them to answer themselves.
>
> maybe we're asking the wrong question...
>
> vanishingly few users are in a position to form any simple rational
> judgement about which keys to trust. they just don't have the knowledge
> and even if they did there are just too many open source release
> managers.
>
> rather than users being asked whether they trust a particular key,
> perhaps it would be better use a system of signed imports. a user may
> decide to trust a list matching keys to groups based on a good maven
> master signature. this puts the control in the hands of the user but
> ensures that they should have the knowledge necessary to make a rational
> judgement. efficient, too.
>
> could use this system to allow users to blacklist keys too.
>
> - robert
>
>
>
Re: maven2 based releases for the james project and ASF policy
Posted by robert burrell donkin <rd...@apache.org>.
On Mon, 2006-09-25 at 11:05 +1000, Brett Porter wrote:
> On 23/09/2006, at 10:31 PM, robert burrell donkin wrote:
<snip>
> > given that the repository is secure then a checksum should be good
> > enough and is easier for users to understand.
>
> I'd certainly like to start there with the options in the document.
> So, cleaning up the checksums in the repository, making sure Maven
> can pull them from the source repository rather than a mirror, and
> allowing them to be hardcoded into the POM would all make for a
> reasonable security system.
in terms of a replacement attack where someone subverts a mirror, i
would say so.
AIUI both MD5 and SHA1 have been broken in a technical sense but should
be ok from a practical perspective for the next few years. i don't think
that we need to worry overly about this
since we use detached signatures, if these hashing algorithms are
considered too weak for our purposes, we would need to be very careful
about the signing algorithms we allow and choose only algorithms which
do not rely on these hash algorithms. we would also need to ensure that
the key lengths were chosen carefully.
digital signatures definitely provide a lot of extra security at a low
cost but do require knowledge to interpret.
> However, I got the indication that some people wouldn't think this
> was sufficient.
i don't think that checking checksums alone is sufficient but it is a
start.
checking checksums should be good enough for most users provided that
the trustworthiness of the checksums can be guaranteed. it's this last
bit which is difficult. i don't see any easy solution to this.
> > it's really about the trust model.
> >
> > one issue is that determined attackers could easily this system if
> > second or third had signatures are trusted transitively. mallory
> > legitimately gets a connection to the web of trust then fakes an
> > entire
> > sub-graph populated by fictional characters. this would be very
> > convincing to an automated system with only moderate risk to
> > mallory who
> > could claim ignorance of the scam when confronted.
>
> Right. I think this is best counteracted by checking both the trust
> in the person's key, and a secondary method of associating them with
> the project that you are checking. That's starting to make the system
> a bit complicated though.
if you know that the key is used to sign releases for that project then
the identity of the signer is not relevant.
> > multiple signatures for each release may be a good way to cheaply
> > increase security. the release managers could sign, the maven uploader
> > could also sign to indicate that they had verified the release
> > managers
> > signature. a maven auto-signer could add another signature to indicate
> > that it had been uploaded through the official mechanism. a scoring
> > system could be used to present this information to the user.
>
> This is interesting, but I worry that the complexity makes it harder
> for the user to really answer the question of whether they trust it.
a scoring system is just a simple way to present the result in a form
which does not require a lot of knowledge. for example:
* trusted autosign
*** trusted autosign plus trusted uploader signature or trusted
release manager
***** trusted autosign plus trusted uploader signature plus trusted
release manager signature
i think that most users would understand 5 star security rating better
than the explanation the right. it's also less to read. maybe expert
users could customise the scoring system.
> I think it needs to be a simple question for them to answer themselves.
maybe we're asking the wrong question...
vanishingly few users are in a position to form any simple rational
judgement about which keys to trust. they just don't have the knowledge
and even if they did there are just too many open source release
managers.
rather than users being asked whether they trust a particular key,
perhaps it would be better use a system of signed imports. a user may
decide to trust a list matching keys to groups based on a good maven
master signature. this puts the control in the hands of the user but
ensures that they should have the knowledge necessary to make a rational
judgement. efficient, too.
could use this system to allow users to blacklist keys too.
- robert
Re: maven2 based releases for the james project and ASF policy
Posted by robert burrell donkin <rd...@apache.org>.
On Mon, 2006-09-25 at 12:15 +0100, Steve Loughran wrote:
> On 25/09/06, Brett Porter <br...@apache.org> wrote:
> >
> > On 23/09/2006, at 10:31 PM, robert burrell donkin wrote:
> >
> > >
> > > perhaps (but then why not use standard jar signing...?)
> >
> > I pointed that out in the proposal - that can be used when suitable,
> > but the repository generally needs to be independent of Java solutions.
>
> Java classloaders behave differently with signed jars, ways that are
> not fully compatible with the OSS ethos. Specifically, non-empty
> packages in signed JARs become sealed against classes/resources from
> other JARs not signed by the same signatory. So I'd lose my right to
> insert a new class into org.apache.log4J, org.apache.tools.ant.tasks,
> etc, not without stripping the signatures off the original JARs. You
> can already encounter this problem with Java1.4 and Xerces and our
> friend 'sealing violation'.
that's a good enough reason for me
- robert
Re: maven2 based releases for the james project and ASF policy
Posted by Steve Loughran <st...@gmail.com>.
On 25/09/06, Brett Porter <br...@apache.org> wrote:
>
> On 23/09/2006, at 10:31 PM, robert burrell donkin wrote:
>
> >
> > perhaps (but then why not use standard jar signing...?)
>
> I pointed that out in the proposal - that can be used when suitable,
> but the repository generally needs to be independent of Java solutions.
Java classloaders behave differently with signed jars, ways that are
not fully compatible with the OSS ethos. Specifically, non-empty
packages in signed JARs become sealed against classes/resources from
other JARs not signed by the same signatory. So I'd lose my right to
insert a new class into org.apache.log4J, org.apache.tools.ant.tasks,
etc, not without stripping the signatures off the original JARs. You
can already encounter this problem with Java1.4 and Xerces and our
friend 'sealing violation'.
Re: maven2 based releases for the james project and ASF policy
Posted by Brett Porter <br...@apache.org>.
On 23/09/2006, at 10:31 PM, robert burrell donkin wrote:
>
> perhaps (but then why not use standard jar signing...?)
I pointed that out in the proposal - that can be used when suitable,
but the repository generally needs to be independent of Java solutions.
>
> i think that the substantial question is whether a hierarchical trust
> model is more suitable for release verification than a distributed
> one.
ok.
>
> one of the problems is that a web-of-trust cannot be used without
> knowledge. a user must understand the difference between a good
> signature by an untrusted key and a bad signature by a trusted key. i
> think that (with effort) this could be explained in a few hundred
> words
> but the user would need to read it.
This is true. It may be wise to make this available, but not the
default. We need to balance out the advantage of basic security
instead of no security, vs. giving a false sense of security by
making it too transparent.
>
> given that the repository is secure then a checksum should be good
> enough and is easier for users to understand.
I'd certainly like to start there with the options in the document.
So, cleaning up the checksums in the repository, making sure Maven
can pull them from the source repository rather than a mirror, and
allowing them to be hardcoded into the POM would all make for a
reasonable security system.
However, I got the indication that some people wouldn't think this
was sufficient.
> it's really about the trust model.
>
> one issue is that determined attackers could easily this system if
> second or third had signatures are trusted transitively. mallory
> legitimately gets a connection to the web of trust then fakes an
> entire
> sub-graph populated by fictional characters. this would be very
> convincing to an automated system with only moderate risk to
> mallory who
> could claim ignorance of the scam when confronted.
Right. I think this is best counteracted by checking both the trust
in the person's key, and a secondary method of associating them with
the project that you are checking. That's starting to make the system
a bit complicated though.
> multiple signatures for each release may be a good way to cheaply
> increase security. the release managers could sign, the maven uploader
> could also sign to indicate that they had verified the release
> managers
> signature. a maven auto-signer could add another signature to indicate
> that it had been uploaded through the official mechanism. a scoring
> system could be used to present this information to the user.
This is interesting, but I worry that the complexity makes it harder
for the user to really answer the question of whether they trust it.
I think it needs to be a simple question for them to answer themselves.
[snip rest I generally agree with]
- Brett
Re: maven2 based releases for the james project and ASF policy
Posted by robert burrell donkin <rd...@apache.org>.
On Fri, 2006-09-22 at 16:06 +1000, Brett Porter wrote:
> On 19/09/06, robert burrell donkin <rd...@apache.org> wrote:
<snip>
> > i don't understand why a single key should be shipped. seems a bit
> > hierarchical, bit more like a certificate. what happens if that key has
> > to be revoked?
>
> I'm afraid I'm going to need someone with more expertise on the topic
> to shed some light on this aspect. Perhaps a certificate is more
> suitable.
perhaps (but then why not use standard jar signing...?) but hierarchical
trust models can also be used with OpenPGP.
i think that the substantial question is whether a hierarchical trust
model is more suitable for release verification than a distributed one.
> > the user is going to be asked to trust the integrity of the maven
> > release and the default selection of keys whether it's one or many.
>
> Yes, but I think that's required anyway. Anyone who'd convince you to
> download something that is an altered release could simply take out
> the key checks (or leave it there and add their own key as you say so
> it looks the same but silently allows malicious code).
true
> I;m not sure
> there's a way we can get around that other to ensure the initial down
> is signed and strongly encourage checking it on the download page.
one of the problems is that a web-of-trust cannot be used without
knowledge. a user must understand the difference between a good
signature by an untrusted key and a bad signature by a trusted key. i
think that (with effort) this could be explained in a few hundred words
but the user would need to read it.
given that the repository is secure then a checksum should be good
enough and is easier for users to understand.
> > when using a web-of-trust model the obvious keys to ship are those which
> > are most connected. taking a look at the ASF web-of-trust
> > (http://people.apache.org/~henkp/trust/apache.html) shipped a dozen or
> > keys well used keys would give good coverage.
>
> That could be a better alternative if having a Maven key to sign them
> doesn't make practical sense.
it's really about the trust model.
if using a web-of-trust model, shipping a single trusted maven key
really makes little sense. it would be better to use network analysis to
ship the 50 (say) best connected keys from the key signing graph and to
trust those by default. for example, ken has signed many other keys over
the years. by trusting ken's key you are able to verify the identity of
many keys directly and a huge number by second or third hand (six
degrees of separation).
one issue is that determined attackers could easily this system if
second or third had signatures are trusted transitively. mallory
legitimately gets a connection to the web of trust then fakes an entire
sub-graph populated by fictional characters. this would be very
convincing to an automated system with only moderate risk to mallory who
could claim ignorance of the scam when confronted.
when using a hierarchical model, the keys shipped as trusted should be
the ultimately trusted roots. in this case, it would make sense to ship
a master maven key.
> > note that if this maven key has a special role in the proposed then it
> > would need to be kept very secret. this means that signing subkeys with
> > limited durations would have to be used to sign the majority of
> > artifacts. some libraries have issues with signing subkeys.
>
> Yeah, this is probably one big argument against it. If instead of a
> Maven key we have individual keys signing each other than we don't
> have to worry about the secure location of the maven private key.
yep: the problem is that the utility of the key is inversely
proportional to it's security. IIRC i have around 100 signed releases
out there. i keep my key on an isolated hardened installation and sign
release only there. IMHO a maven master key would need to be kept with
this level of security. this means that the key could not be used for
day-to-day signing operations. a separate key changed regularly would be
the way to do actual signing of releases. but this would require that
maven understands the age of a release so that the expiry dates could be
correctly checked.
multiple signatures for each release may be a good way to cheaply
increase security. the release managers could sign, the maven uploader
could also sign to indicate that they had verified the release managers
signature. a maven auto-signer could add another signature to indicate
that it had been uploaded through the official mechanism. a scoring
system could be used to present this information to the user.
one issue that the maven repository is going to find is that by allowing
unsigned releases an attacker can easily subvert the system by removing
the signature file. this would not even require that the machine be
cracked: it could be done using DNS misdirection (AIUI this attack is
relatively common these days).
IMO the repository should sign every artifact uploaded in order to
prevent this attack. the key used to autosign should be accorded a low
trust score and changed periodically. shortly before each key expires
every artifact would need to have another signature added for this new
key.
> > > Should a user not wish to accept this initial set of keys, they can
> > > simply remove the installation key ring and manually install keys they
> > > wish to trust.
> >
> > i'm confused. AIUI the keys in a keyring are by default not trusted.
> > having keys in the keyring means that they do not need to be fetched
> > from a server or obtained manually. assigning trusting is an extra
> > step.
> >
> > if maven wants to set up an openpgp compatible keyring with trusted
> > defaults then a private key would need to be generated for each keyring
> > during installation. to do this properly means an interactive session.
> > the user could be prompted to trust or not trust a sequence of
> > recommendations during this session.
>
> I probably hadn't thought the implementation of thatt area through
> enough - I was anticipating that the Maven default key(s) would be
> trusted already and the user would intervene in adding extras.
>
> Will give this section more thought.
establishing a viable keyring with a web-of-trust would require user
intervention but establishing a keyring to cache public keys would not.
> > > or KEYS file (as specified in settings.xml - see below), not from the
> > > repository that the artifact is being downloaded from.
> >
> > i'm a little confused about this. it doesn't matter where the key is
> > obtained from: what question is identity. the question is which keys to
> > trust for what purposes.
>
> Right, but surely a KEYS file on the actual web server is the closest
> we'll get to a trusted source if you haven't met someone in person?
a KEYS file is much more trustworthy for the purpose of release
verification from a downloader's perspective. the question is not the
identity of the signer but that the key used to sign the downloaded
document is the that which should have been used to sign the release.
the KEYS file allows me to find the fingerprint of the key that should
have been used to sign that release. the key used to create the
signature should be download from a keyserver and the signature
verified. check both that the signature is good and that the fingerprint
of the key used to sign that release is the value it should be.
a strong web of trust is about securing the repository against attack.
the idea is that any repository maintainer (who should know - or be able
to find out - who cut each release) who is strongly connected by the web
of trust to the release managers can verify every signature without
needing to use the KEYS files. this property is very useful to have in
the event of a repository compromise.
> > > By default, all keys in the user's keyring will be accepted. However,
> > > to strengthen a requirement, a project may require that the key be a
> > > particular one, or signed by a particular key. The key provided might
> > > be either an email address or the key ID.
> >
> > email address is absolutely worthless. keyID is not secure. the
> > fingerprint should be used.
>
> This was really to restrict the keys trusted for a certain dependency
> (I trust open symphony for webwork, but I don't for commons-logging).
> So the fingerprint would definitely be used in establishing the trust
> of the publci key you already have.
i agree that this is a useful property.
my point is only that the email address or keyID should not be used.
both are too easy to subvert. only the fingerprint is good enough. so, a
project should include the fingerprint for the key used to sign that
release (and not keyID or email address).
- robert
Re: maven2 based releases for the james project and ASF policy
Posted by Brett Porter <br...@gmail.com>.
On 19/09/06, robert burrell donkin <rd...@apache.org> wrote:
> > The Maven installation will contain a private key used to sign Maven
> > PMC members release keys.
>
> typo? should this be public key?
Yes, thanks.
> i don't understand why a single key should be shipped. seems a bit
> hierarchical, bit more like a certificate. what happens if that key has
> to be revoked?
I'm afraid I'm going to need someone with more expertise on the topic
to shed some light on this aspect. Perhaps a certificate is more
suitable.
>
> the user is going to be asked to trust the integrity of the maven
> release and the default selection of keys whether it's one or many.
Yes, but I think that's required anyway. Anyone who'd convince you to
download something that is an altered release could simply take out
the key checks (or leave it there and add their own key as you say so
it looks the same but silently allows malicious code). I;m not sure
there's a way we can get around that other to ensure the initial down
is signed and strongly encourage checking it on the download page.
> when using a web-of-trust model the obvious keys to ship are those which
> are most connected. taking a look at the ASF web-of-trust
> (http://people.apache.org/~henkp/trust/apache.html) shipped a dozen or
> keys well used keys would give good coverage.
That could be a better alternative if having a Maven key to sign them
doesn't make practical sense.
> note that if this maven key has a special role in the proposed then it
> would need to be kept very secret. this means that signing subkeys with
> limited durations would have to be used to sign the majority of
> artifacts. some libraries have issues with signing subkeys.
Yeah, this is probably one big argument against it. If instead of a
Maven key we have individual keys signing each other than we don't
have to worry about the secure location of the maven private key.
>
> > Should a user not wish to accept this initial set of keys, they can
> > simply remove the installation key ring and manually install keys they
> > wish to trust.
>
> i'm confused. AIUI the keys in a keyring are by default not trusted.
> having keys in the keyring means that they do not need to be fetched
> from a server or obtained manually. assigning trusting is an extra
> step.
>
> if maven wants to set up an openpgp compatible keyring with trusted
> defaults then a private key would need to be generated for each keyring
> during installation. to do this properly means an interactive session.
> the user could be prompted to trust or not trust a sequence of
> recommendations during this session.
I probably hadn't thought the implementation of thatt area through
enough - I was anticipating that the Maven default key(s) would be
trusted already and the user would intervene in adding extras.
Will give this section more thought.
>
> > Note that in both of the above cases, they key should be downloaded
> > from a trusted keyserver
>
> no public keyserver can be trusted to trusted keys: they make no promise
> about identity
I'm not even sure what I meant there now. Will look again :)
>
> > or KEYS file (as specified in settings.xml - see below), not from the
> > repository that the artifact is being downloaded from.
>
> i'm a little confused about this. it doesn't matter where the key is
> obtained from: what question is identity. the question is which keys to
> trust for what purposes.
Right, but surely a KEYS file on the actual web server is the closest
we'll get to a trusted source if you haven't met someone in person?
> > By default, all keys in the user's keyring will be accepted. However,
> > to strengthen a requirement, a project may require that the key be a
> > particular one, or signed by a particular key. The key provided might
> > be either an email address or the key ID.
>
> email address is absolutely worthless. keyID is not secure. the
> fingerprint should be used.
This was really to restrict the keys trusted for a certain dependency
(I trust open symphony for webwork, but I don't for commons-logging).
So the fingerprint would definitely be used in establishing the trust
of the publci key you already have.
> if a project requires that a particular key is used then the
> web-of-trust should be ignored and that key downloaded from a public
> server and the signature checked by that key. in this case, it's
> probably not safe to consider keys trusted by this key as trusted. the
> web-of-trust model vouches for identity not authorization.
Right.
Thanks for all the feedback! I'll try and clarify the document based
on it, but it's certainly given me more to think about.
Cheers,
Brett
Re: maven2 based releases for the james project and ASF policy
Posted by robert burrell donkin <rd...@apache.org>.
On Mon, 2006-09-18 at 08:30 +1000, Brett Porter wrote:
> On 17/09/06, Stefano Bagnara <ap...@bago.org> wrote:
> > One of James PMC members is concerned (and we, other PMC member, agree
> > on his concerns) about the security issues introduced by downloading
> > artifacts from ibiblio or its mirrors, so we are trying to find an
> > interim solution while ASF define a common way.
>
> BTW, as I'm sure Noel is listening - I'm still waiting on his feedback
> to the proposal I put up specifically about his concerns.
>
> http://docs.codehaus.org/display/MAVEN/Repository+Security+Improvements
i've listed a some comments below about the details below but i'm a
little worried about whether the trust model is well enough thought
through. i think issues of key acquisition and trust have become a
little tangled up together.
but i'm very glad that someone's finally been willing to stick their
head about the parapet and create a concrete proposal
(from document)
> The Maven installation will contain a private key used to sign Maven
> PMC members release keys.
typo? should this be public key?
i don't understand why a single key should be shipped. seems a bit
hierarchical, bit more like a certificate. what happens if that key has
to be revoked?
the user is going to be asked to trust the integrity of the maven
release and the default selection of keys whether it's one or many.
when using a web-of-trust model the obvious keys to ship are those which
are most connected. taking a look at the ASF web-of-trust
(http://people.apache.org/~henkp/trust/apache.html) shipped a dozen or
keys well used keys would give good coverage.
or maybe i'm missing something important...
> It may also be used to sign other ASF releases, and sync providers
> keys.
the more signatures the better
note that if this maven key has a special role in the proposed then it
would need to be kept very secret. this means that signing subkeys with
limited durations would have to be used to sign the majority of
artifacts. some libraries have issues with signing subkeys.
> Should a user not wish to accept this initial set of keys, they can
> simply remove the installation key ring and manually install keys they
> wish to trust.
i'm confused. AIUI the keys in a keyring are by default not trusted.
having keys in the keyring means that they do not need to be fetched
from a server or obtained manually. assigning trusting is an extra
step.
if maven wants to set up an openpgp compatible keyring with trusted
defaults then a private key would need to be generated for each keyring
during installation. to do this properly means an interactive session.
the user could be prompted to trust or not trust a sequence of
recommendations during this session.
> Note that in both of the above cases, they key should be downloaded
> from a trusted keyserver
no public keyserver can be trusted to trusted keys: they make no promise
about identity
> or KEYS file (as specified in settings.xml - see below), not from the
> repository that the artifact is being downloaded from.
i'm a little confused about this. it doesn't matter where the key is
obtained from: what question is identity. the question is which keys to
trust for what purposes.
> By default, all keys in the user's keyring will be accepted. However,
> to strengthen a requirement, a project may require that the key be a
> particular one, or signed by a particular key. The key provided might
> be either an email address or the key ID.
email address is absolutely worthless. keyID is not secure. the
fingerprint should be used.
if a project requires that a particular key is used then the
web-of-trust should be ignored and that key downloaded from a public
server and the signature checked by that key. in this case, it's
probably not safe to consider keys trusted by this key as trusted. the
web-of-trust model vouches for identity not authorization.
- robert
Re: maven2 based releases for the james project and ASF policy
Posted by Stefano Bagnara <ap...@bago.org>.
Hi Brett,
I read your proposal maybe more than 1 month ago, and it seems very good
to me.
IIRC this is something still being discussed and there is no real
roadmap (no developer to be assigned) for it to be included in the next
maven 2.1 release: is this correct?
Otherwise, can you give an ETA for this stuff? I don't want to hurry
you, I just would like to have an estimate time (1 month? 3 months? 1
year?) so that we can take it into consideration while discussing
alternative interim solutions.
I CC general@james.apache.org (where Noel was discussing with us about
this topic, before I moved to repository@ to find further suggestions)
so we've much more probability Noel is listening.
Stefano
Brett Porter wrote:
> On 17/09/06, Stefano Bagnara <ap...@bago.org> wrote:
>> One of James PMC members is concerned (and we, other PMC member, agree
>> on his concerns) about the security issues introduced by downloading
>> artifacts from ibiblio or its mirrors, so we are trying to find an
>> interim solution while ASF define a common way.
>
> BTW, as I'm sure Noel is listening - I'm still waiting on his feedback
> to the proposal I put up specifically about his concerns.
>
> http://docs.codehaus.org/display/MAVEN/Repository+Security+Improvements
>
> On this thread, one gotcha I'll note about using file:/ repositories -
> it may be difficult to get them to work as expected in a multiple
> module project. They can still work, it just requires redefining them
> in all POMs that use it, you can't inherit it with the correct
> directory settings.
>
> Thanks,
> Brett
>>
>> Here is what I've proposed:
>>
>> 1) create a "repository/third-party-m1" folder in our
>> svn.apache.org/repos/asf/james repository.
>>
>> 2) commit there our current third party dependencies (BSD/CDDL/MIT/ASF)
>>
>> 3) export the content of this repository on a subfolder of our
>> james.apache.org website (james.apache.org/repos/third-party-m1 could be
>> a good candidate) so that we don't link directly the SVN server but a
>> mirrored resource (websites are mirrored, right?)
>>
>> 4) add this "james.apache.org/repos/third-party-m1" to our main pom
>> (overwriting ibiblio).
>>
>>
>> We would still use the 2 ASF-wide maven repositories to publish our
>> official release or to read ASF jars and for our snapshots needs.
>>
>>
>> Does ASF policy allow us to do this? WDYT?
>>
>> Stefano
RE: maven2 based releases for the james project and ASF policy
Posted by "Noel J. Bergman" <no...@devtech.com>.
Brett Porter wrote:
> BTW, as I'm sure Noel is listening - I'm still waiting on his feedback
> to the proposal I put up specifically about his concerns.
> http://docs.codehaus.org/display/MAVEN/Repository+Security+Improvements
Hadn't a clue until Stefano mentioned it today.
I'll try to get to it during the week, or you can catch up with me at
ApacheCon.
As for Stefano's proposal, I agree with the views expressed by Dims, Steve
and Henri.
--- Noel
Re: maven2 based releases for the james project and ASF policy
Posted by Brett Porter <br...@gmail.com>.
On 17/09/06, Stefano Bagnara <ap...@bago.org> wrote:
> One of James PMC members is concerned (and we, other PMC member, agree
> on his concerns) about the security issues introduced by downloading
> artifacts from ibiblio or its mirrors, so we are trying to find an
> interim solution while ASF define a common way.
BTW, as I'm sure Noel is listening - I'm still waiting on his feedback
to the proposal I put up specifically about his concerns.
http://docs.codehaus.org/display/MAVEN/Repository+Security+Improvements
On this thread, one gotcha I'll note about using file:/ repositories -
it may be difficult to get them to work as expected in a multiple
module project. They can still work, it just requires redefining them
in all POMs that use it, you can't inherit it with the correct
directory settings.
Thanks,
Brett
>
> Here is what I've proposed:
>
> 1) create a "repository/third-party-m1" folder in our
> svn.apache.org/repos/asf/james repository.
>
> 2) commit there our current third party dependencies (BSD/CDDL/MIT/ASF)
>
> 3) export the content of this repository on a subfolder of our
> james.apache.org website (james.apache.org/repos/third-party-m1 could be
> a good candidate) so that we don't link directly the SVN server but a
> mirrored resource (websites are mirrored, right?)
>
> 4) add this "james.apache.org/repos/third-party-m1" to our main pom
> (overwriting ibiblio).
>
>
> We would still use the 2 ASF-wide maven repositories to publish our
> official release or to read ASF jars and for our snapshots needs.
>
>
> Does ASF policy allow us to do this? WDYT?
>
> Stefano
>
>
--
Apache Maven - http://maven.apache.org
"Better Builds with Maven" book - http://library.mergere.com/
Re: maven2 based releases for the james project and ASF policy
Posted by Henri Yandell <fl...@gmail.com>.
On 9/16/06, Stefano Bagnara <ap...@bago.org> wrote:
> Hi all,
>
> I know there is an ongoing thread about ASF/maven2 repositories and
> third party library, but it seems to me that we won't have an ASF-wide
> solution in few weeks, am I right?
>
> We (Apache James project) have two "new" products based on maven2 that
> are ready to be released: jSPF and Mime4J.
>
> Both projects depends on third party (license compatible) jars and our
> snapshots currently depends on a maven repository I set up in my
> minotaur home to be able to build the projects.
>
> Of course this is no good because we can't publish official releases
> including references to my home or including references to SNAPSHOT
> projects.
>
> One of James PMC members is concerned (and we, other PMC member, agree
> on his concerns) about the security issues introduced by downloading
> artifacts from ibiblio or its mirrors, so we are trying to find an
> interim solution while ASF define a common way.
>
> Here is what I've proposed:
>
> 1) create a "repository/third-party-m1" folder in our
> svn.apache.org/repos/asf/james repository.
>
> 2) commit there our current third party dependencies (BSD/CDDL/MIT/ASF)
>
> 3) export the content of this repository on a subfolder of our
> james.apache.org website (james.apache.org/repos/third-party-m1 could be
> a good candidate) so that we don't link directly the SVN server but a
> mirrored resource (websites are mirrored, right?)
>
> 4) add this "james.apache.org/repos/third-party-m1" to our main pom
> (overwriting ibiblio).
>
>
> We would still use the 2 ASF-wide maven repositories to publish our
> official release or to read ASF jars and for our snapshots needs.
>
>
> Does ASF policy allow us to do this?
Yes, provided the third party jars are ones the ASF can redistribute
(see the 3rd party legal stuff).
Infra opinions might be against the idea of putting build dependables
on a project's website. An alternative would be to have a
people.apache.org/repo/james/ repository, but that's just sneaking
into official repositories that are disliked at the moment.
> WDYT?
I like Dims' idea of doing it within the file system for the time
being. I'm not particularly a believer in the network independence
part of it - I tend to find that I still need the network for Maven to
get a plugin I wasn't expecting to need, but it does mean that you
don't have to support the repository on your project website on an
on-going basis.
When an ASF repository exists (or one that we have strong trust in),
then you could switch to using that.
Hen
Re: maven2 based releases for the james project and ASF policy
Posted by Carlos Sanchez <ca...@apache.org>.
If you use a filesystem based repo it won't be possible to publish
your artifacts in the maven repo because it must be self contained
(other than license issues)
You may setup a profile for users that want to use a local copy
instead of going to the internet.
On 9/16/06, Davanum Srinivas <da...@gmail.com> wrote:
> Stefano,
>
> I was thinking about the same thing for the last few days :) Here's
> something that will work. It's a variant on your steps.
>
> Start with your #1, #2, but skip #3 and in #4 instead of a http url
> specify the directory on the hard disk where the svn checkout of the
> third-party-m1 directory is present.
>
> <repository>
> <id>james-private-repo</id>
> <name>James Private Repository</name>
> <url>file:${basedir}/../../third-party-m1</url>
> <releases>
> <enabled>true</enabled>
> </releases>
> <snapshots>
> <enabled>true</enabled>
> </snapshots>
> </repository>
>
> What does this buy us?
> - We don't need to overload infra or worry about mirrors.
> - No need to worry about the web site.
> - Complete control over the jars
> - No network traffic as the jars are on the hard disk.
> - When we make a release the source zip is self-contained (no network
> access needed, no need to worry about jars disappearing from remote
> maven repos)
>
> What do you think?
>
> -- dims
>
> On 9/16/06, Stefano Bagnara <ap...@bago.org> wrote:
> > Hi all,
> >
> > I know there is an ongoing thread about ASF/maven2 repositories and
> > third party library, but it seems to me that we won't have an ASF-wide
> > solution in few weeks, am I right?
> >
> > We (Apache James project) have two "new" products based on maven2 that
> > are ready to be released: jSPF and Mime4J.
> >
> > Both projects depends on third party (license compatible) jars and our
> > snapshots currently depends on a maven repository I set up in my
> > minotaur home to be able to build the projects.
> >
> > Of course this is no good because we can't publish official releases
> > including references to my home or including references to SNAPSHOT
> > projects.
> >
> > One of James PMC members is concerned (and we, other PMC member, agree
> > on his concerns) about the security issues introduced by downloading
> > artifacts from ibiblio or its mirrors, so we are trying to find an
> > interim solution while ASF define a common way.
> >
> > Here is what I've proposed:
> >
> > 1) create a "repository/third-party-m1" folder in our
> > svn.apache.org/repos/asf/james repository.
> >
> > 2) commit there our current third party dependencies (BSD/CDDL/MIT/ASF)
> >
> > 3) export the content of this repository on a subfolder of our
> > james.apache.org website (james.apache.org/repos/third-party-m1 could be
> > a good candidate) so that we don't link directly the SVN server but a
> > mirrored resource (websites are mirrored, right?)
> >
> > 4) add this "james.apache.org/repos/third-party-m1" to our main pom
> > (overwriting ibiblio).
> >
> >
> > We would still use the 2 ASF-wide maven repositories to publish our
> > official release or to read ASF jars and for our snapshots needs.
> >
> >
> > Does ASF policy allow us to do this? WDYT?
> >
> > Stefano
> >
> >
>
>
> --
> Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
Re: maven2 based releases for the james project and ASF policy
Posted by Steve Loughran <st...@gmail.com>.
On 16/09/06, Davanum Srinivas <da...@gmail.com> wrote:
> Stefano,
>
> I was thinking about the same thing for the last few days :) Here's
> something that will work. It's a variant on your steps.
>
> Start with your #1, #2, but skip #3 and in #4 instead of a http url
> specify the directory on the hard disk where the svn checkout of the
> third-party-m1 directory is present.
>
> <repository>
> <id>james-private-repo</id>
> <name>James Private Repository</name>
> <url>file:${basedir}/../../third-party-m1</url>
> <releases>
> <enabled>true</enabled>
> </releases>
> <snapshots>
> <enabled>true</enabled>
> </snapshots>
> </repository>
>
> What does this buy us?
> - We don't need to overload infra or worry about mirrors.
> - No need to worry about the web site.
> - Complete control over the jars
> - No network traffic as the jars are on the hard disk.
> - When we make a release the source zip is self-contained (no network
> access needed, no need to worry about jars disappearing from remote
> maven repos)
>
> What do you think?
this is probably what any project that uses the repositories ends up
doing. In private projects you can add all the restricted JARs, like
j2ee.jar, and not get into trouble, but in OSS projects its more
complex. A repository under apache SCM still can only host stuff under
licenses that the management approve of. That may be apache license
only, or it may scale out to some others. Sun-restricted and (L)GPL
would be out. \
-steve
Re: maven2 based releases for the james project and ASF policy
Posted by Stefano Bagnara <ap...@bago.org>.
Hi dims,
thank you for this suggestion! I never used a file url in the repository
definition and it sounds interesting..
The main problem I can see with this solution is that people have to do
a manual step (download third-party-m1 to a specific folder) before
being able to build.
As an example people that will download the src package will find a
pom.xml but running "mvn" on it won't work because they won't have this
third-party-m1 repository in their system, and we have to make them
manually do this step.
As another example when I'll put my pom url into continuum it will not
be able to build it because it does not have the third-party-m1 jars and
I can't see a simple solution if not add a cron or a manual script to
keep them synchronized.
I'm just thinking at a solution (less than optimal because of jars
duplication, but maybe better overall) where each project has its own
repos/third-party-m1 folder in the source tree: we have no restricted
jars in our dependencies now that Sun released activation/javamail under
the CDDL.
So one of my projects (jspf) would have this repository definition:
----
<repository>
<id>local-jspf-3rd-party-m1</id>
<name>Local jSPF third party repository</name>
<url>file://${basedir}/repos/third-party-m1</url>
<layout>legacy</layout>
<releases>
<enabled>true</enabled>
<checksumPolicy>ignore</checksumPolicy>
</releases>
<snapshots>
<enabled>true</enabled>
<checksumPolicy>ignore</checksumPolicy>
</snapshots>
</repository>
-----
Then I would have to change the assembly.xml in order to put the repos
folder in our src distribution: does this make sense?
I just made a proof and it seems to work for a single project: now I'm
going to test this in a multiproject environment. I guess I will have
problems with transitive dependencies, but I have to do some test to
understand this.
Anyone else ever tested a similar solution?
Stefano
Davanum Srinivas wrote:
> Stefano,
>
> I was thinking about the same thing for the last few days :) Here's
> something that will work. It's a variant on your steps.
>
> Start with your #1, #2, but skip #3 and in #4 instead of a http url
> specify the directory on the hard disk where the svn checkout of the
> third-party-m1 directory is present.
>
> <repository>
> <id>james-private-repo</id>
> <name>James Private Repository</name>
> <url>file:${basedir}/../../third-party-m1</url>
> <releases>
> <enabled>true</enabled>
> </releases>
> <snapshots>
> <enabled>true</enabled>
> </snapshots>
> </repository>
>
> What does this buy us?
> - We don't need to overload infra or worry about mirrors.
> - No need to worry about the web site.
> - Complete control over the jars
> - No network traffic as the jars are on the hard disk.
> - When we make a release the source zip is self-contained (no network
> access needed, no need to worry about jars disappearing from remote
> maven repos)
>
> What do you think?
>
> -- dims
Re: maven2 based releases for the james project and ASF policy
Posted by Davanum Srinivas <da...@gmail.com>.
Stefano,
I was thinking about the same thing for the last few days :) Here's
something that will work. It's a variant on your steps.
Start with your #1, #2, but skip #3 and in #4 instead of a http url
specify the directory on the hard disk where the svn checkout of the
third-party-m1 directory is present.
<repository>
<id>james-private-repo</id>
<name>James Private Repository</name>
<url>file:${basedir}/../../third-party-m1</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
What does this buy us?
- We don't need to overload infra or worry about mirrors.
- No need to worry about the web site.
- Complete control over the jars
- No network traffic as the jars are on the hard disk.
- When we make a release the source zip is self-contained (no network
access needed, no need to worry about jars disappearing from remote
maven repos)
What do you think?
-- dims
On 9/16/06, Stefano Bagnara <ap...@bago.org> wrote:
> Hi all,
>
> I know there is an ongoing thread about ASF/maven2 repositories and
> third party library, but it seems to me that we won't have an ASF-wide
> solution in few weeks, am I right?
>
> We (Apache James project) have two "new" products based on maven2 that
> are ready to be released: jSPF and Mime4J.
>
> Both projects depends on third party (license compatible) jars and our
> snapshots currently depends on a maven repository I set up in my
> minotaur home to be able to build the projects.
>
> Of course this is no good because we can't publish official releases
> including references to my home or including references to SNAPSHOT
> projects.
>
> One of James PMC members is concerned (and we, other PMC member, agree
> on his concerns) about the security issues introduced by downloading
> artifacts from ibiblio or its mirrors, so we are trying to find an
> interim solution while ASF define a common way.
>
> Here is what I've proposed:
>
> 1) create a "repository/third-party-m1" folder in our
> svn.apache.org/repos/asf/james repository.
>
> 2) commit there our current third party dependencies (BSD/CDDL/MIT/ASF)
>
> 3) export the content of this repository on a subfolder of our
> james.apache.org website (james.apache.org/repos/third-party-m1 could be
> a good candidate) so that we don't link directly the SVN server but a
> mirrored resource (websites are mirrored, right?)
>
> 4) add this "james.apache.org/repos/third-party-m1" to our main pom
> (overwriting ibiblio).
>
>
> We would still use the 2 ASF-wide maven repositories to publish our
> official release or to read ASF jars and for our snapshots needs.
>
>
> Does ASF policy allow us to do this? WDYT?
>
> Stefano
>
>
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)