On 1/22/16 4:43 AM, Markus Lehtonen wrote: > Hi Mark, > > > > (CC'd the mailing list which was accidentally dropped from my previous email) > > On 21/01/16 17:21, "Mark Hatle" <mark.ha...@windriver.com> wrote: > >> On 1/21/16 5:20 AM, Markus Lehtonen wrote: >>> On Wed, 2016-01-13 at 12:28 +0200, Markus Lehtonen wrote: >>>> On Tue, 2016-01-12 at 18:24 +0200, Markus Lehtonen wrote: >>>>> Hi Mark, >>>>> >>>>> Thank you for your review! Comments below. >>>>> >>>>> On Mon, 2016-01-11 at 10:33 -0600, Mark Hatle wrote: >>> >>> [...SNIP...] >>> >>>>>> >>>>>> Why are you removing existing signatures? I believe for many cases this >>>>>> is >>>>>> actually incorrect. >>>>>> >>>>>> RPM (5) has the ability to have an endless number of signatures within a >>>>>> given >>>>>> package. The package SHOULD included the internal non-repudiable >>>>>> signature... >>>>>> >>>>>> (to refresh memory) all RPM 5 packages include an internal non-repudiable >>>>>> signature. Think of this as an extended md5sum, sha256sum, etc. It >>>>>> doesn't >>>>>> change that a package is 'authentic' in any way (often the purpose of >>>>>> signatures >>>>>> like what this code is doing), but instead keeps a high reliability way >>>>>> to sign >>>>>> and verify the package is signed properly. >>>>>> >>>>>> This is used for validation if the system doing the install does not >>>>>> have the >>>>>> public key that the package was signed with. >>>>>> >>>>>> ... as well as one or more repudiable signatures that can be used to >>>>>> verify that >>>>>> it's "authentic" in some way. A system could very easily have OSV, OEM, >>>>>> and ISV >>>>>> keys install on them. You can program RPM in such a way that it will >>>>>> refused to >>>>>> install packages with unknown authentication keys or the non-repudiable >>>>>> key as well. >>>>>> >>>>>> So, I believe running delsign is wrong. If the obs-signd can't handle >>>>>> ADDING >>>>>> signatures to packages, then I'd say it is broken and should be fixed in >>>>>> some >>>>>> way -- or at least the signature deletion code should be optional. >>>>> >>>>> Yes, unfortunately this is currently the limitation of obs-signd. It >>>>> refuses to sign if there are signatures present in the rpm package. >>>>> Using --delsign is "unfortunate" consequence of this and that should've >>>>> probably been described in a comment. Making signature deletion a >>>>> configurable setting is hopefully a decent resolution for now. I will >>>>> send a new version of the patchset later. >>>> >>>> Backing up a bit here. I did some quick testing and it seems that RPM5 >>>> does not support multiple signatures (anymore?). Doing --addsign seems >>>> to overwrite the existing signatures similarly to --resign. Support for >>>> multiple signatures were removed from RPM4 years ago. >>>> >>>> In this light, doing --delsign should be ok. What do you think? >>> >>> Hi Mark. Do you have any comments to the above? I'd like to get this >>> patchset out of my hands :) >> >> RPM5 does have multiple signatures, but only allows one of each of the three >> types to be installed. The delsign shouldn't be used as it might remove the >> wrong signature. > > AFAIU, rpm only allows one signature so be present. The file format allows > that, but, the rpm tool does not (anymore). For example, rpm --addsign will > remove an existing DSA signature when adding an RSA signature. The SHA1 / MD5 > digests are not touched by --delsign. > > >> (Three types are DSA/RSA, ECDSA, and simple SHA256 or similar.) > > I didn't know that rpm(5?) supports ECDSA signatures. > > >> But making the --delsign optional I think is the best approach. (It would be >> better to move it to the obs-sign script itself -- but I can live with doing >> it >> on the OE side since people are trying to use their owns systems.) > > I still believe that making it optional is just worthless and complicates > things because doing rpm --addsign has exactly the same effect. > > >> The alternative would be to not call the script 'obs-sign', but instead call >> an >> arbitrarily named (and defined in a bitbake variable) script.. Then THAT >> script >> can do the del and call the obs-sign.) > > Hmm, I probably don't like this idea that much. This user-written script > would need to be a bit more complex as a it needs to support multiple > operations (signrpm, detach sign, export pubkey). Of course, I could write a > default script and put it under scripts/ but somehow feels more complex than > needed.
The more I look at this, the more I think that makes sense. I've had some of my (WR Linux) release guys look at this, and the obs-sign mechanism will not work for us. So we're going to have to write some custom signing code anyway. It will be much easier if there is a generic interface. The previous thought was to use the obs-sign "interface", but write our own... but at that point OBS has nothing to do with it.. It's just really being used as a signing interface. I'm assuming at this point that we're not alone in this need. I've talked to a variety of commercial people and they all have slightly different signing policies and mechanisms. Everything from, we don't sign the packages but check separate checksums -- to we sign locally with a local keyring key -- to we sign locally with a special in-memory key -- to after every package is built we have to upload the package to an (internal password protected) FTP/HTTP site and trigger it to be signed, then once signed we download it. (And of course OBS specific signing...) I think in this case an external script makes this all much easier for someone to implement their specific policy and procedures, especially with a defined API. Including default scripts with this as useful runners or examples would definitely be a part of the work in my mind. --Mark > > Thanks, > Markus > > -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
