on organization(id)s

[Doug Tangren]

Going forward, is it a good idea to keep the java history of declaring organization ids in artifact metadata?

I know we need something for this to adapt to past systems like mvn and ivy, but I wonder if we could "choose" to make this a little transparent. In a world where content distribution is moving more towards the individual and away from company (in some cases) the choice of an organization id (reverse dns in particular) is becoming an arbitrary because tools like ivy and mvn depend on it being declared. Some individuals make the choice of using the reverse dns of where the artifacts are hosted, com.github.user,  ect. This is a little silly because those artifacts get copied around and in some cases eventually end up in mvn central. Source code locations change, artifact hosts change. These arbitrary ( and forced ) organization id selections are silly. 

In other communities, your dependencies are sufficiently identified by a project name and a version. I believe this simpler approach is more user friendly because a) a library user is not forced to memorize a meaningless identifier ( sometimes of arbitrary meaning as mentioned above ) and b ) library author is required to fill in less required field ( less required friction when publishing ).

The main argument I see for keeping organization ids around is name-spacing to avoid naming conflicts with library names. I believe this is not needed with a proper library naming scheme. If your library is distributed with multiple modules, prefix them, i.e. dispatch-core, dispatch-json, ... Don't label your library something ambiguous like "core"! Name-spacing could also be addressed by the system used to track libraries and packages. We could employ a first come first service system bower ( http://twitter.github.com/bower/ ) does this for instance. 

I really like the idea of doing away with organization ids both for consumers and for produces of libraries. I tried my best to hide this in implicit.ly ls ( http://ls.implicit.ly/#publishing ) falling back on github user and repo as a fall back for namespacing.

I wanted to hear other thoughts on the topic so I thought I'd post here.

-Doug Tangren
http://lessis.me

[Josh Suereth]

I really think you nailed all the discussion points except for one: identity verification and authorization.

On thing domain named have is a registered user who you can ask if they've authorized libraries to be published in their domain.   It gives you a gateway to control who publishes your library and prevent bootleg instances.

In practice, I don't really think anyone uses that aspect, but it's a nice ivory tower we can point at and say "we trust these things".

Personally I'd much rather use PGP identitities and let people authorize others through key signing.   That's what the whole system was designed to do, not just encrypt and send, but verify identity and authorization.

I think we've had these talks before.   I'd love for adept to have seamless and painless security built in, but I'm not sure that's ever possible with security.   However, its an aspect to consider if we want to dump artifact ids.

[eugene yokota]

+1 for PGP.

-eugene

[Wes Freeman]

I like the domain name solution. If you don't own a domain maybe a github username/organization is an alternative.

Leiningen (Clojure's build tool) recently added PGP signing for publishing, with future plans for Clojars (the Clojure maven-central) for a "releases" repository where only PGP signed releases (non-snapshot) go. It's kind of clunky as implemented, but I think it was missing from the Clojure solution for a long time. Just mentioning...

Wes

[Josh Suereth]

Glad to hear that!  I heard lots of things about clojars, but hadn't heard how they actually planned to deal with security.   

We should have good PGP support out of the box.   We can even make it a "silent" part of the namespacing, as an idea...

Remember ->  WE should divorce computer-readable metadata from the UX.  You can do so many nicer things....

- Josh

[eugene yokota]

In general it'd be nice to get rid of human approval process for publishing metadata while maintaining integrity.

Taking from Doug's ls idea, we could have a hard-coded project name like "adept.pubkey" for advertising PGP public key(s).

For example, https://raw.github.com/dispatch/adept.pubkey/master/adept.pubkey could list all committers public keys.

This could automatically grant "github:://dispatch" as orgid for those keys.

Similarly, if you publish https://twitter.com/adept.pubkey, that could grant "http://twitter.com" as orgid.

To deal with name changes, mergers, etc, there probably should be traditional human maintained pairing,

but the above methods should make human interaction an exception not the rule.

This requires all artifacts to be signed with PGP.

One consequence s that the source of trust is de-centralized.

This relates to Doug's other thread of uber vs personal metadata repo,

but every time you get someone's jar, we'd have to hit either totally random website or github,

which might not fly if you're behind a corporate firewall environment.

Maybe there's a default centralized PGP pubkey repository (similar to ls.implicit.ly).

All you have to do is to nudge it to check some source (https or github), and it'd cache the keys.

-eugene

[Wes Freeman]

Yeah, a combination of decentralized and centralized might be good. Using both together would even provide more security than one or the other.

With clojars they actually embed the PGP public keys in the user profile on their website. Which at least is an added layer of security for clojars as a repository, but it doesn't let the library consumers validate it themselves (the signatures are in the repo, but I don't know if there's a mechanism to actually get a user's public key--maybe that's coming soon). In theory someone could figure out your clojars.org password and replace your PGP key and post some malicious jars in your name, AFAIK.

Wes

[Mark Harrah]

Agree with:

1. domain name/group ID/organization should be unnecessary and can be verbose
2. PGP- my thoughts were that however git signs commits would be enough for us. There are some details to work out depending on how metadata repos work (one or many, ...)
3. no human approval process for publishing

Disagree with:

1. anything that depends too much on a particular host or style of hosting, like GitHub.

-Mark

[Josh Suereth]

Well, for pgp, it's not terribly hard to roll our own flows for keys.   Bouncy Castle is a surprisingly powerful library.

I don't think just signing commits is enough.   That tells you who changed metadata, but not fine grained "should they be able to change that metadata".

I do think, when posting metadata, having a public key which represents the authority to publish.   You can then sign other peoples keys with metadata (like adept-deployer), and we can use this to validate if a key is authorized.

Maybe after some coffee I'll have better ideas on flow, but most of them revolve around the idea that we have a key associated with a repo, and that key signs humans keys to grant access, in an automated fashion.  On any given machine, the humans key is used to sign everything, and we have some mechanism to ask for approval for that key to publish somewhere remote.

I even think the tool should have built in pgp support and not rely on gpg or existing keys.  Mostly because some aspects of PGP remain unimplemented in gpg, and I'm not sure we want their trust model.