Greg Brown wrote: >>> Let me attempt to clarify my suggestion. Artifacts would never actually be >>> submitted to /lib/signed. This would be a "virtual" directory, so to speak. >>> Unsigned JARs would be deployed to /lib, signed on the fly by the web >>> server, and cached in /lib/signed. >> Given that we run code in process (which becomes more fun with mod_lua) >> I don't consider that a sufficient security boundary on the signing key. > > Fair enough. Oh well. It seemed like a good idea, anyways. :-) > > So, assuming that it is a submit unsigned JAR/receive signed JAR service, how > do you envision authentication might work?
Stay tuned :) Better yet, I'm going to take the conversation entirely over to [email protected] starting tomorrow afternoon (giving folks a chance to subscribe if they don't, already). Let's spare incubator and security some of the traffic for a while, now that people have chimed in. But in a nutshell, commit a jar/asc gpg signature to dist.apache.org/, and it recommits a flavor signed with the original signer's credentials embedded. Not sure how this will behave, exactly, for jar's just yet. So it's two part authentication, your gpg signature and your svn credentials. Do we need a way to bulk-submit elements of a package for signing, and if so, what would that format be? Then the service would unpack the set (.jar/.zip? Or .tar? .msi?) sign the components and repack it. If we go with the service, this will be quite different than I envisioned. You would log in, submit an object and receive an object back. But from what we need to sign at httpd for win32 dll's, and how Harmony seems to be packaged, this could prove really unwieldy.
