Re: IMA signing questions
Hi Ken,
>
> I want to add "intro to IMA signing" instructions to
> https://docs.pagure.org/koji/signing/ . I wrote a basic PR at
> https://pagure.io/koji/pull-request/3206 but it lacks technical
> details.
That'd be cool!
>
> - How do I generate my own new keypair so I can IMA-sign an RPM?
You can generate the key with the standard OpenSSL commands.
For example, an RSA key can be generated like:
openssl genrsa | openssl pkcs8 -topk8 -nocrypt -outform DER -out privatekey.der
(do note that the key will need to be in DER format).
You can then generate a corresponding (self-signed) certificate for validation
with:
openssl req -x509 -key privatekey.der -out certificate.pem -days 365 -keyform
DER
>
> - Can I use my existing GPG keypair?
Mathematically, yes. Practically, no.
The key format RPM (libimaevm) reads for signing is DER, so you'd have to
convert the actual key bits from the GPG format to DER.
>
> - How do I IMA-sign files in an RPM locally (apart from Koji)? (Is it
> the --signfiles option from rpmsign(8)?)
Yes, it's the --signfiles option.
>
> - How do I inspect the IMA signatures on an existing RPM?
The signatures are stored in the FILESIGNATURES rpm sighdr (with tag
RPMTAG_SIG_BASE + 18, so 274), as a hex-encoded string array.
I have some code for reading and parsing the signatures at
https://github.com/fedora-iot/rpm-head-signing/blob/main/rpm_head_signing/extract_rpm_with_filesigs.py
.
>
> - When I gpg-sign an RPM with "Key A" and IMA-sign an RPM with "Key
> B", does Koji "know" about Key B at all?
Koji at this moment does not look at or touch the FILESIGNATURES header.
It copies it into its signature store (because the tag is in the sighdr), and
will re-insert it into the resulting RPM, but it has no clue it's even there.
This also means that the RPMs that are signed with {rpm_key=keyA, ima_key=keyB}
and {rpm_key=keyA, ima_key=keyC} are seen as having the same signature, and
thus would result in the hub rejecting the new signature until the old one gets
removed.
It would absolutely be useful to have this information also stored in koji and
a part of the index for the signatures, but that hasn't been done yet.
Patrick
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)
> * Peter Robinson: > > > If the signatures end up in RPM headers, they will land in the RPM > database, too. > > “rpm -qla | wc -l” shows around 28,589 files for me, in the Fedora 33 > container image. / seems to need 183 MiB right now. If the signatures > land in the RPM database and the file system, I expect at least 96 bytes > per file signature (digests in the header are traditionally hex-encoded, > I think). That translates to 2.6 MiB, or ~1.4% size increase. > > But quite likely there is some per-block overhead, so the numbers should > be worse. > > Hi, I did some experimentation with the size differences of both the binary RPM packages and the RPMDB if the packages would contain IMA signatures. I took all the packages in the Fedora base container image (registry.fedoraproject.org/fedora:latest), removed the Fedora signatures, and then got two copies of that: one with just GPG signed, one with IMA signatures and then GPG signed. The size of the binary RPMs: 77412 ima-signed-pkgs 76632 rawpkgs 75660 signedpkgs So on the binary RPMs, I am seeing a 2% increase. After that, I created two containers, one where I reinstalled all the packages with the resigned versions and one where I reinstalled all the packages with the IMA resigned versions, and then looked at the RPMDB sizes: Resigned: 14732 /var/lib/rpm IMA + Resigned: 16332 /var/lib/rpm So in the RPMDB, this comes down to a 11% increase. However, to be noted here is that this is 15 or 16MB on a 584MB base image, so it's about a 0.3% increase of size compared to the base image itself. Note that if you do not install the "rpm-plugin-ima", that is the only impact: RPM will only actually put the extended attributes in place once you install that package. For more notes on how I got these results, see my notes at https://puiterwijk.fedorapeople.org/ima-size-research . > The private key. IMA is typically used for some form of remote > attestation, I think. I'm not sure if it is possible to distribute > hardware with IMA enforcement. And as long as enforcement can be turned > of trivially (as required by the GPLv3, as far as I can tell), IMA seems > to be pretty useless. The default IMA policy in the kernel measures and attests nothing. You would need to manually deploy an IMA policy with a line like "audit uid=0" for any file signature verification to be performed (in this case, on files opened as root). After you have enabled policy lines like these, it's impossible to remove them without rebooting, but the system starts without a policy. So you would need to manually deploy the policy, after which systemd loads it as one of the very first steps of the boot process and it takes effect. Regards, Patrick ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)
> https://fedoraproject.org/wiki/Changes/Signed_RPM_Contents > I'd like to point out that after many requests, I have updated the change page for this significantly, with more details as to the goals (and non-goals) of this feature, and answers to many other questions asked. Please have another look if you are interested in this. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Stuck PPC64 build
Hi, > On Mon, Nov 14, 2016 at 12:03:33PM -0700, Jerry James wrote: > > puiterwijk possibly. Yes. For now, you can just ping me on IRC, or create a ticket on https://pagure.io/fedora-infrastructure to get a PPC64(LE) instance on our Infrastructure cloud. In the near future, we hope to open up self-service instance creation so that people can spin up their own PPC64(LE) instances without needing to create a ticket, but I'll email the list when that time comes. > > Zbyszek Regards, Patrick Uiterwijk ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: upcoming build and release developer flag day December 12 2016
> On 2016-11-20, 01:11 GMT, Dennis Gilmore wrote: > > a) Is it possible to have multiple tickets, each from different > realm? When I do kinit mcepl(a)FEDORAPROJECT.ORG, klist lookslike my > @REDHAT.COM ticket has been knocked out (i.e., thereis only FPO > ticket there). Ah, klist -A seems to be theanswer. Yes, this works, however, koji does not automatically select the right TGT. As such, you will need to run "kswitch -p $usern...@fedoraproject.org" when you go work on Fedora. I have a patch in koji for GSSAPI support, but that's been idle/awaiting upstream review/changes. > b) We do have to do the Firefox Kerberos-dance anyway > (https://developer.mozilla.org/en-US/docs/Mozilla/Integrated_authentication), >right? Somebody should mention that, so I do. With Firefox 49 and later, the trusted-uris setting is set to https:// by default, which means you don't need to change anything. > c) Despite doing all this I don’t see myself logged-in to Koji. What > am I missing? We have not enabled web login for Koji. I will be looking at that in the near future, but that's not a main goal. For now, the CLI should work, which you can verify with "koji hello". > > Best, > > Matěj Regards, Patrick ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: upcoming build and release developer flag day December 12 2016
> On 11/21/2016 10:32 AM, Florian Weimer wrote: > > Yes, as I mentioned elsewhere, we should probably have the fedora-packager RPM > ship with a krb5.conf.d snippet that sets the appropriate values. You mean something like http://pkgs.fedoraproject.org/cgit/rpms/fedora-packager.git/commit/?id=b3ab149d144a644f41705e4ec7b5e36a25892e95 ? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: upcoming build and release developer flag day December 12 2016
> Dne 21.11.2016 v 16:07 Alexander Bokovoy napsal(a): > > > $ KRB5_TRACE=/dev/stderr kinit vondruch(a)FEDORAPROJECT.ORG > [8655] 1479746886.252240: Resolving unique ccache of type KEYRING > [8655] 1479746886.252281: Getting initial credentials for > vondruch(a)FEDORAPROJECT.ORG > [8655] 1479746886.252439: Sending request (205 bytes) to FEDORAPROJECT.ORG > [8655] 1479746886.252542: Resolving hostname id.fedoraproject.org > [8655] 1479746886.380979: Terminating TCP connection to https > 2604:1580:fe00:0:dead:beef:cafe:fed1:443 > [8655] 1479746886.383242: Terminating TCP connection to https > 2610:28:3090:3001:dead:beef:cafe:fed3:443 > [8655] 1479746886.754122: TLS certificate name matched > "id.fedoraproject.org" > [8655] 1479746886.926836: Sending HTTPS request to https 140.211.169.206:443 > [8655] 1479746887.331375: HTTPS error receiving from https > 140.211.169.206:443 > [8655] 1479746887.333212: Terminating TCP connection to https > 140.211.169.206:443 > [8655] 1479746887.594719: TLS certificate name matched > "id.fedoraproject.org" > [8655] 1479746887.710694: Sending HTTPS request to https 67.219.144.68:443 > [8655] 1479746888.330867: HTTPS error receiving from https 67.219.144.68:443 > [8655] 1479746888.331797: Terminating TCP connection to https > 67.219.144.68:443 > [8655] 1479746888.694098: TLS certificate name matched > "id.fedoraproject.org" > [8655] 1479746888.862462: Sending HTTPS request to https 67.203.2.67:443 > [8655] 1479746889.122858: HTTPS error receiving from https 67.203.2.67:443 > [8655] 1479746889.123787: Terminating TCP connection to https > 67.203.2.67:443 > [8655] 1479746889.527941: TLS certificate name matched > "id.fedoraproject.org" > [8655] 1479746889.722994: Sending HTTPS request to https 209.132.181.16:443 > [8655] 1479746889.964857: HTTPS error receiving from https > 209.132.181.16:443 > [8655] 1479746889.965718: Terminating TCP connection to https > 209.132.181.16:443 > [8655] 1479746890.363509: TLS certificate name matched > "id.fedoraproject.org" > [8655] 1479746890.552022: Sending HTTPS request to https 209.132.181.15:443 > [8655] 1479746890.787479: HTTPS error receiving from https > 209.132.181.15:443 > [8655] 1479746890.788339: Terminating TCP connection to https > 209.132.181.15:443 > [8655] 1479746891.68629: TLS certificate name matched "id.fedoraproject.org" > [8655] 1479746891.201442: Sending HTTPS request to https 152.19.134.198:443 > [8655] 1479746891.711140: HTTPS error receiving from https > 152.19.134.198:443 > [8655] 1479746891.711960: Terminating TCP connection to https > 152.19.134.198:443 > [8655] 1479746892.55922: TLS certificate name matched "id.fedoraproject.org" > [8655] 1479746892.214348: Sending HTTPS request to https 66.35.62.162:443 > [8655] 1479746892.563662: HTTPS error receiving from https 66.35.62.162:443 > [8655] 1479746892.564576: Terminating TCP connection to https > 66.35.62.162:443 > [8655] 1479746892.945989: TLS certificate name matched > "id.fedoraproject.org" > [8655] 1479746893.119732: Sending HTTPS request to https 140.211.169.196:443 > [8655] 1479746893.512855: HTTPS error receiving from https > 140.211.169.196:443 > [8655] 1479746893.513684: Terminating TCP connection to https > 140.211.169.196:443 > [8655] 1479746893.812319: TLS certificate name matched > "id.fedoraproject.org" > [8655] 1479746893.944132: Sending HTTPS request to https 152.19.134.142:443 > [8655] 1479746894.412080: HTTPS error receiving from https > 152.19.134.142:443 > [8655] 1479746894.412908: Terminating TCP connection to https > 152.19.134.142:443 > kinit: Cannot contact any KDC for realm 'FEDORAPROJECT.ORG' while > getting initial credentials Downgrade to openssl-1.1.0b: https://github.com/openssl/openssl/issues/1919 > > > > Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: upcoming build and release developer flag day December 12 2016
> On 11/21/2016 08:07 AM, Vít Ondruch wrote: > > > So, it turns out that this doesn't work yet. It's complicated, but there's a > patch pending for Koji that will make this work. It hasn't landed yet. > Hopefully > that will change before the flag day. And I'm thrilled to say that my patch to get GSSAPI support into Koji has been merged a few hours ago! Once the Fedora package has been updated (which I hope happens sometime very soon), it should all work magically out of the box. The server side is already live on our staging instance, and will go live on production in the next few days: [puiterwijk@localhost puiterwijk]$ stg-koji hello jó napot, puiterwijk! You are using the hub at https://koji.stg.fedoraproject.org/kojihub Authenticated via GSSAPI ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: upcoming build and release developer flag day December 12 2016
> On 11/21/2016 03:51 PM, Patrick マルタインアンドレアス Uiterwijk wrote: > > > Exactly like that, yes. It isn't present (yet?) on Fedora 25, though I see now > it's been added to Rawhide. Right, I dropped the ball there for a bit while testing. However, I'm building for epel6,epel7,f23,f24,f25 today, so this should go out soon. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Creating an new update is failing
Hi, > Hello, > > I'm trying to create a new update and > I'm getting this error: > > Builds : Unable to create update. Parent instance is not bound to a Session; > lazy load > operation of attribute 'release' cannot proceed > > The build looks fine: > http://koji.fedoraproject.org/koji/buildinfo?buildID=821471 > > Any ideas what the problem is? I'm very sorry for the problems here, they should now be fixed. > > tia, > > steved. Regards, Patrick ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: out of space on some builders
> Looks like there are problems on some builders: Then reporting koji errors, it would be great if you could attach the task link so that we can check. > > BuildrootError: could not init mock buildroot, mock exited with status > 1; see build.log for more information > > And there is no build.log. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Packagers - Flag day 2016 Important changes
> On 12/12/2016 04:53 AM, Vít Ondruch wrote: > > There are patches still coming that will switch the fedora packaging tools to > use GSSAPI rather than Kerberos directly, which will handle auto-selecting the > right TGT. I'm not sure what the status is on this, but Patrick Uiterwijk > (CCed) > was looking into it. This is live in production, and the code is in koji-1.11.0, so updating to that will make automatic selection work. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: How attached are we to branch ACLs? -- Should we kill pkgdb?
> As I already mentioned in person when this came up in a DevConf talk, I > think that this is a plan that will likely break a lot of things, especially > the expectations all our users rely on (that everything in Everything has a > consistent guaranteed life time), and that doing away with that expectation > is going to make Fedora a lot less useful for many of our users (including > myself and probably also other contributors). Guaranteeing a life time for > the modules included in specific deliverables (spins, "editions", etc.) does > not help, because in the real world, users install many add-on packages from > our repository, its size is one of the main strengths of Fedora. > > ... Note that this question is not about removing the subbranches for releases, it is purely about removing the feature where you can have different access lists for different branches. So, if we go with Pierre's suggestion, we would still have a Fedora 25 and Fedora 26 branch, but you would no longer be able to say that "Patrick has commit for Fedora 25 but not Fedora 26". So this should not impact the life time guarantees or anything else that the branches give us. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: s390x build failures
> Thanks and sorry for not searching first ;) I am the one who started a new thread :). Tried to make sure it stood out. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: fedpkg new-sources broken?
> Hi, > > > I seem to be unable to upload a new tarball for freefem++: > > $ fedpkg new-sources freefem++-3.56.tar.gz > /usr/lib/python2.7/site-packages/fedora/client/bodhi.py:48: > DeprecationWarning: fedora.client.bodhi has been deprecated. Please use > bodhi.client.bindings instead. >DeprecationWarning) > Uploading: freefem++-3.56.tar.gz > > 100.0% > Could not execute new_sources: Fail to upload files. Server returns > status 502 > > > Any ideas about what is going on here? We were testing a fix for the double-upload. Could you let us know what versions you have of: fedora-packager fedpkg curl python2-pycurl libcurl. Also, please retry now, as we have reverted the server-side change that likely made you hit this. > > Ralf Patrick ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Koji build: cannot find spec file
> On 02/17/2018 08:22 PM, Jerry James wrote: > > Yeah, it's still broken. I looked at it a bit but couldn't see what the > exact cause of the breakage is. ;( > > If we cannot get it fixed by tomorrow morning, I'll revert us back to > the older koji version. ;( We have found and fixed the issue with koji 1.15.0, and patched the build system. Builds should be working as of now again. > > Sorry for the hassles. > > kevin Thanks for your patience, Patrick ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Goodbye nvr.rsplit('-', 2), hello modularity
> On 15/03/18 15:30, Patrick Uiterwijk wrote:
>
> Well currently at any rate? What's the long term story?
>
> Only when some module rpms accidentally leaked into rawhide
> recently they definitely had the kind of rather unhelpful names
> that you described in your post and I got the impression at
> the time that it was anticipated they might come to rawhide
> for real at some point.
Note that the module builds I was talking about are the actual modules, not the
module content.
The RPMs that ended up in rawhide standard repos (which was a bug, they should
have gone to, and will go to a Modular side-repo), are standard RPMS with NVR
like $packagename-$version-$release.module_$tag.
In other words, the packages that end up in the repos fit the NVR pattern, it's
just that the release part has its .%{dist} replaced with .module_%{tag}.
My email was about module description builds as you'd submit them to Bodhi for
example, like https://koji.fedoraproject.org/koji/buildinfo?buildID=1055963.
>
> Tom
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: f28 and rawhide ignoring static ip settings
> On 03/15/2018 01:23 PM, Tomasz Torcz 👁️ wrote: > > It's not. Now it's enp0s3. > > And renaming /etc/sysconfig/network-scripts/ifcfg-ens3 to ifcfg-enp0s3 > doesn't do anything. Note that the files themselves also contain a DEVICE= line that would need to be updated for it to apply again. Patrick ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Goodbye nvr.rsplit('-', 2), hello modularity
> Don't be afraid of koji. :) I couldn't agree more, Koji's a pretty nice project to work on. It might seems scary for newcomers because of all the ingrained knowledge and assumptions, but once you get close the community is nice and friendly :). > > It is under active development. Of course, resources are limited and not > everything can be taken on, but it's worth having the discussion. I have > filed https://pagure.io/koji/issue/851 as a strawman and will try to > solicit feedback on the idea. > Thanks for doing that, though I don't know that it would resolve my challenges. First, I'd like to point out that by now I've basically solved the problems for Bodhi and know how to deal with this change. The main reason I wanted to send this email is because in things like fedmsg's and other things, the NVRs as imported by Koji still leak out. Even if the identifiers are colon-separated in all places and the N-S-V encoded version is never exported out of koji, people will still need to update scripts and tooling, and bringing that to people's attention was my main reason for sending the email. I absolutely did not mean for my email to be judgemental, as I've not been privy to the decision to allow dashes in multiple fields or the rest, so I can't really judge the reasoning or the conclusion. If it came over as judging, I'm sorry, I really just wanted to give people a headsup so that they have some upfront time to update scripts before seeing eithe module identifiers in fedmsg's or any other place. > Patrick, if https://pagure.io/koji/issue/851 was implemented would that > resolve the challenge you were facing? If not, it might be worth reaching > out to koji-devel(a)lists.fedorahosted.org and discussing it further there. It would not, but that's okay. It would still mean that Module identifiers, whether you notice them as N-S-V.C or N:S:V:C, are new, and all tooling and scripts will need to be updated to handle those new identifiers. > > Cheers > -- Dennis Patrick ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: "invalid path: ~/.fedora-server-ca.cert"
Hi, You very likely have an /etc/koji.conf.rpmnew. Could you please move that over /etc/koji.conf? If not, maybe you have a ~/.koji, with custom config, you might need to remove. If you have neither, can you make sure you have at least these package versions (from [1]): python2-cccolutils-1.4-1 fedpkg-1.26-2 fedora-packager-0.6.0.0-1 pyrpkg-1.47-3 koji-1.11.0-1 This custom CA has been entirely retired and unused for over a year, so some old configuration is still referring to it. [1]: https://fedoraproject.org/wiki/ReleaseEngineering/FlagDay2016 Patrick ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
