https://fedoraproject.org/w/api.php?action=feedcontributions&user=Puiterwijk&feedformat=atomFedora Project Wiki - User contributions [en]2024-03-19T08:44:33ZUser contributionsMediaWiki 1.39.4https://fedoraproject.org/w/index.php?title=Changes/Signed_RPM_Contents&diff=601325Changes/Signed RPM Contents2021-01-20T23:27:47Z<p>Puiterwijk: /* Documentation */</p>
<hr />
<div>= Signed RPM Contents =<br />
<br />
== Summary ==<br />
We want to add signatures to individual files that are part of shipped RPMs.<br />
These signatures will use the Linux IMA (Integrity Measurement Architecture) scheme, which means they can be used to enforce runtime policies to ensure execution of only trusted files.<br />
<br />
== Owner ==<br />
* Name: [[User:Puiterwijk| Patrick Uiterwijk]]<br />
* Email: puiterwijk@redhat.com<br />
* Name: [[User:Pbrobinson| Peter Robinson]]<br />
* Email: pbrobinson@gmail.com<br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<br />
== Current status ==<br />
[[Category:ChangeReadyforFesco]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
[[Category:SystemWideChange]]<br />
<br />
* Targeted release: [[Releases/34 | Fedora 34 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
ASSIGNED -> accepted by FESCo with ongoing development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* FESCo issue: [https://pagure.io/fesco/issue/2547 #2547]<br />
* Tracker bug: <will be assigned by the Wrangler><br />
* Release notes tracker: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
During signing builds, the files in it will be signed with IMA signatures.<br />
These signatures will be made with a key that’s kept by the Fedora Infrastructure team, and installed on the sign vaults.<br />
<br />
These signature can then be used with the Linux Integrity Measurement Architecture (IMA) kernel subsystem to verify files on execution based on a policy.<br />
<br />
The IMA subsystem is described on [https://sourceforge.net/p/linux-ima/wiki/Home/ the project page].<br />
<br />
IMA allows users to extend the trust of their system to the OS and processes.<br />
This means that they can configure a policy based on which the kernel will determine whether to verify (or measure) files before opening them.<br />
You could for example make a policy that appraises (verifies) all files that are executed by root: `appraise uid=1000 appraise_type=imasig`.<br />
<br />
Note explicitly that we do not intend to install a default policy as part of this change, and users will need to deploy their own policy before anything is measured or appraised.<br />
This means that after this is done, users will have the option to enable a policy and have that be enforced, but there will be nothing automatic.<br />
We will, however, document various example policies people can adapt to their needs.<br />
<br />
By default, the signatures will not be deployed to the file system. That will only be done once rpm-plugin-ima is installed.<br />
After that, RPM will put the signatures on the "security.ima" extended attribute on the files.<br />
<br />
== Feedback ==<br />
<br />
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. --><br />
<br />
<br />
=== RPM Size ===<br />
One of the main concerns that have been voiced is the RPM size, both on disk (mirrors) and on an installed system.<br />
For this comparison, I have cached all the RPMs installed in a Fedora Rawhide 20210118.n.1 default Server install (server netinstall disk, and then no changed to the group selection).<br />
After creating two copies of that data, one with just resigned (to exclude rpm size difference resulting from different key lengths), and one resigned with IMA file signatures inserted, I then installed two blank VMs by using the standard virt-manager settings, changing only the name and the system type to "EFI".<br />
<br />
This is using a prime256v1 file signing key. This is the same key format supported by the Fedora signing system.<br />
<br />
==== Binary RPMs on disk ====<br />
Resigned: 462524 (452M)<br />
<br />
Resigned+IMA: 467812 (457M)<br />
<br />
This comes down to a 1.1% increase on size of the binary RPMs.<br />
<br />
<br />
==== Installed size ====<br />
On installation of two different VMs, one with the resigned RPMs, and one with the resigned+ima RPMs, the `/usr` directory size does not change at all (both are exactly 1417064 bytes).<br />
<br />
The size of the rpmdb increases from 22952 to 28416 bytes, a 20% increase.<br />
This is on an install size of 1.7GB in total, so this 5MB increase is a 0.3% size increase on the final installed system.<br />
<br />
Note that both of those VMs did not have rpm-plugins-ima installed, which means the file signatures are not put in place.<br />
<br />
When I install the rpm-plugin-ima, and run "dnf reinstall *", the `/usr` directory increases by 0.002% to 1417104.<br />
<br />
<br />
<br />
=== Tie-in to Secure Boot ===<br />
<br />
While using the IMA subsystem in combination with Secure Boot enables users to extend trust on the system out into the binaries executed, there is no requirement at all to use secure boot.<br />
This means that if you have Secure Boot enabled, that enables you to extend the trust, but if you don't want to use secure boot, that has no impact on the IMA subsystem.<br />
<br />
<br />
=== Why in the RPM header, instead of a side-package like -debuginfo? ===<br />
<br />
These signatures would need to get deployed as a filesystem extended attribute in order to be used by the IMA subsystem.<br />
While it is possible to generate the signatures as separate files in a side package, that means that RPM would then need to add code to install extended attributes based on contents of another RPM package.<br />
This would mean that the contents of an e.g. `-file-signature` subpackage won't be deployed to the file systems as normal files, but instead as xattr's on existing files.<br />
<br />
That, together with the minimal size increases of the actual RPMs, made us decide to go with the signature header approach and not implement the side-package method.<br />
<br />
<br />
=== Comparison with MAC's ===<br />
<br />
The IMA subsystem is orthogonal to the Mandatory Access Control systems like selinux, though it is integrated with them.<br />
<br />
Where with selinux you can limit who can read from or write to to which file, IMA will allow you to set policies that enforce file contents to be as expected (signature validated) before they can be read/executed.<br />
<br />
The integration is in the form that you can write a policy line that matches on certain selinux contexts, like for example `dont_appraise obj_type=var_log_t`, to ensure that files of `var_log_t` do not need to be verified, and `appraise obj_type=shell_exec_t` to ensure that any shell that is executed (e.g. bash) is signed with a trusted key.<br />
<br />
<br />
=== Why not ... ===<br />
<br />
==== fsverity ====<br />
<br />
As one of the fsverity maintainers has said on [https://lwn.net/Articles/842326/|LWN]: IMA and FS-Verity are not mutually exclusive, but at this moment IMA has a possibility to enforce a system-wide policy instead of needing the userspace binaries to check the signature status themselves.<br />
<br />
<br />
==== rpm -V ====<br />
<br />
rpm -V will tell you whether a file matches the digest that's in the RPM Database, but that is useful if you think a file might have been accidentally changed. If an attacker has the opportunity to change a file on the file system, it is very likely they could also update the RPM binary (or the rpmdb) to make it not report the change.<br />
<br />
IMA signatures will be able to identify the file to have been changed, and importantly also enable a policy which enforces the signatures, which means that if a change was made to a file that is matched by a policy, the kernel would actively refuse loading it, instead of depending on the administrator to check its validity with a known-good rpm database and binary.<br />
<br />
== Benefit to Fedora ==<br />
<br />
Having all files signed with a verifiable key means that system owners can use the kernel Integrity and Measurement Architecture (IMA) to enforce only verified files can be executed, or define other policies.<br />
<br />
Having all files signed with Fedora keys would enable integration with for example [https://keylime.dev/|Keylime], which is a CNCF project that implements remote system attestation, based on which a system may or may not get access to secrets and other consequences.<br />
<br />
This feature is wanted by the IoT Edition, for enabling both attestation and local policy verification.<br />
Many IoT users have expressed interest in this functionality and are already working to build on it.<br />
<br />
== Scope ==<br />
* Proposal owners:<br />
The proposal owners will generate the keys in Infrastructure and get them deployed to the sign vaults, and enable the configuration options for this in robosignatory.<br />
Support for file signatures is already in the deployed versions of sigul and robosignatory.<br />
<br />
* Other developers:<br />
Nothing needed from other developers<br />
<br />
* Release engineering: <br />
A mass rebuild would be nice (as it ensures all packages are signed), but is not required to implement the change itself.<br />
<br />
* Policies and guidelines:<br />
No impact<br />
<br />
* Trademark approval: <br />
No impact<br />
<br />
* Alignment with Objectives: <br />
This aligns with the Internet of Things objective.<br />
<br />
== Upgrade/compatibility impact ==<br />
For standard Fedora users there will be a very tiny increase in rpmdb size. If an advanced user was already signing their own files (for the Fedora shipped RPMs) for IMA functionality, they will just overwrite the existing signature.<br />
<br />
== How To Test ==<br />
You can verify that a signature has been put in place by looking at the extended attribute by running: `getfattr -d -m security.ima /usr/bin/bash` (change `/usr/bin/bash` with the file to check).<br />
<br />
The signatures can be tested “in vitro” by running `evmctl ima_verify --key publiccert.der -v myfile.txt`.<br />
This should result in the system reporting “<filename>: verification is OK”.<br />
The full system could be tested by enrolling the Fedora IMA key to the kernel `_ima` keyring, and adding a policy that verifies (some) files to be verified against the key. (instructions to follow).<br />
<br />
== User Experience ==<br />
If the user deploys an IMA policy to verify all or some files, they should be able to trust the signatures made by the Fedora build system.<br />
<br />
== Dependencies ==<br />
No external package dependencies.<br />
<br />
== Contingency Plan ==<br />
<br />
* Contingency mechanism: If the change is not finished in time, we have probably not yet started signing new files. Signing can easily be disabled by updating the config file should issues arise.<br />
If we did start signing, but haven’t signed everything, that is okay, since then packages will get signed as they’re bumped by developers, and they’ll be all signed in the next major release.<br />
<br />
* Contingency deadline: We could ship with this feature in an unfinished state.<br />
* Blocks release? No<br />
* Blocks product? N/A<br />
<br />
== Documentation ==<br />
We intend to write documentation on how to use the IMA subsystem for docs.fedoraproject.org, but that is orthogonal to this feature itself.<br />
We expect to provide example policies users can use to base their policy on.<br />
<br />
== Release Notes ==</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Changes/Signed_RPM_Contents&diff=601324Changes/Signed RPM Contents2021-01-20T23:24:27Z<p>Puiterwijk: /* Benefit to Fedora */</p>
<hr />
<div>= Signed RPM Contents =<br />
<br />
== Summary ==<br />
We want to add signatures to individual files that are part of shipped RPMs.<br />
These signatures will use the Linux IMA (Integrity Measurement Architecture) scheme, which means they can be used to enforce runtime policies to ensure execution of only trusted files.<br />
<br />
== Owner ==<br />
* Name: [[User:Puiterwijk| Patrick Uiterwijk]]<br />
* Email: puiterwijk@redhat.com<br />
* Name: [[User:Pbrobinson| Peter Robinson]]<br />
* Email: pbrobinson@gmail.com<br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<br />
== Current status ==<br />
[[Category:ChangeReadyforFesco]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
[[Category:SystemWideChange]]<br />
<br />
* Targeted release: [[Releases/34 | Fedora 34 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
ASSIGNED -> accepted by FESCo with ongoing development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* FESCo issue: [https://pagure.io/fesco/issue/2547 #2547]<br />
* Tracker bug: <will be assigned by the Wrangler><br />
* Release notes tracker: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
During signing builds, the files in it will be signed with IMA signatures.<br />
These signatures will be made with a key that’s kept by the Fedora Infrastructure team, and installed on the sign vaults.<br />
<br />
These signature can then be used with the Linux Integrity Measurement Architecture (IMA) kernel subsystem to verify files on execution based on a policy.<br />
<br />
The IMA subsystem is described on [https://sourceforge.net/p/linux-ima/wiki/Home/ the project page].<br />
<br />
IMA allows users to extend the trust of their system to the OS and processes.<br />
This means that they can configure a policy based on which the kernel will determine whether to verify (or measure) files before opening them.<br />
You could for example make a policy that appraises (verifies) all files that are executed by root: `appraise uid=1000 appraise_type=imasig`.<br />
<br />
Note explicitly that we do not intend to install a default policy as part of this change, and users will need to deploy their own policy before anything is measured or appraised.<br />
This means that after this is done, users will have the option to enable a policy and have that be enforced, but there will be nothing automatic.<br />
We will, however, document various example policies people can adapt to their needs.<br />
<br />
By default, the signatures will not be deployed to the file system. That will only be done once rpm-plugin-ima is installed.<br />
After that, RPM will put the signatures on the "security.ima" extended attribute on the files.<br />
<br />
== Feedback ==<br />
<br />
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. --><br />
<br />
<br />
=== RPM Size ===<br />
One of the main concerns that have been voiced is the RPM size, both on disk (mirrors) and on an installed system.<br />
For this comparison, I have cached all the RPMs installed in a Fedora Rawhide 20210118.n.1 default Server install (server netinstall disk, and then no changed to the group selection).<br />
After creating two copies of that data, one with just resigned (to exclude rpm size difference resulting from different key lengths), and one resigned with IMA file signatures inserted, I then installed two blank VMs by using the standard virt-manager settings, changing only the name and the system type to "EFI".<br />
<br />
This is using a prime256v1 file signing key. This is the same key format supported by the Fedora signing system.<br />
<br />
==== Binary RPMs on disk ====<br />
Resigned: 462524 (452M)<br />
<br />
Resigned+IMA: 467812 (457M)<br />
<br />
This comes down to a 1.1% increase on size of the binary RPMs.<br />
<br />
<br />
==== Installed size ====<br />
On installation of two different VMs, one with the resigned RPMs, and one with the resigned+ima RPMs, the `/usr` directory size does not change at all (both are exactly 1417064 bytes).<br />
<br />
The size of the rpmdb increases from 22952 to 28416 bytes, a 20% increase.<br />
This is on an install size of 1.7GB in total, so this 5MB increase is a 0.3% size increase on the final installed system.<br />
<br />
Note that both of those VMs did not have rpm-plugins-ima installed, which means the file signatures are not put in place.<br />
<br />
When I install the rpm-plugin-ima, and run "dnf reinstall *", the `/usr` directory increases by 0.002% to 1417104.<br />
<br />
<br />
<br />
=== Tie-in to Secure Boot ===<br />
<br />
While using the IMA subsystem in combination with Secure Boot enables users to extend trust on the system out into the binaries executed, there is no requirement at all to use secure boot.<br />
This means that if you have Secure Boot enabled, that enables you to extend the trust, but if you don't want to use secure boot, that has no impact on the IMA subsystem.<br />
<br />
<br />
=== Why in the RPM header, instead of a side-package like -debuginfo? ===<br />
<br />
These signatures would need to get deployed as a filesystem extended attribute in order to be used by the IMA subsystem.<br />
While it is possible to generate the signatures as separate files in a side package, that means that RPM would then need to add code to install extended attributes based on contents of another RPM package.<br />
This would mean that the contents of an e.g. `-file-signature` subpackage won't be deployed to the file systems as normal files, but instead as xattr's on existing files.<br />
<br />
That, together with the minimal size increases of the actual RPMs, made us decide to go with the signature header approach and not implement the side-package method.<br />
<br />
<br />
=== Comparison with MAC's ===<br />
<br />
The IMA subsystem is orthogonal to the Mandatory Access Control systems like selinux, though it is integrated with them.<br />
<br />
Where with selinux you can limit who can read from or write to to which file, IMA will allow you to set policies that enforce file contents to be as expected (signature validated) before they can be read/executed.<br />
<br />
The integration is in the form that you can write a policy line that matches on certain selinux contexts, like for example `dont_appraise obj_type=var_log_t`, to ensure that files of `var_log_t` do not need to be verified, and `appraise obj_type=shell_exec_t` to ensure that any shell that is executed (e.g. bash) is signed with a trusted key.<br />
<br />
<br />
=== Why not ... ===<br />
<br />
==== fsverity ====<br />
<br />
As one of the fsverity maintainers has said on [https://lwn.net/Articles/842326/|LWN]: IMA and FS-Verity are not mutually exclusive, but at this moment IMA has a possibility to enforce a system-wide policy instead of needing the userspace binaries to check the signature status themselves.<br />
<br />
<br />
==== rpm -V ====<br />
<br />
rpm -V will tell you whether a file matches the digest that's in the RPM Database, but that is useful if you think a file might have been accidentally changed. If an attacker has the opportunity to change a file on the file system, it is very likely they could also update the RPM binary (or the rpmdb) to make it not report the change.<br />
<br />
IMA signatures will be able to identify the file to have been changed, and importantly also enable a policy which enforces the signatures, which means that if a change was made to a file that is matched by a policy, the kernel would actively refuse loading it, instead of depending on the administrator to check its validity with a known-good rpm database and binary.<br />
<br />
== Benefit to Fedora ==<br />
<br />
Having all files signed with a verifiable key means that system owners can use the kernel Integrity and Measurement Architecture (IMA) to enforce only verified files can be executed, or define other policies.<br />
<br />
Having all files signed with Fedora keys would enable integration with for example [https://keylime.dev/|Keylime], which is a CNCF project that implements remote system attestation, based on which a system may or may not get access to secrets and other consequences.<br />
<br />
This feature is wanted by the IoT Edition, for enabling both attestation and local policy verification.<br />
Many IoT users have expressed interest in this functionality and are already working to build on it.<br />
<br />
== Scope ==<br />
* Proposal owners:<br />
The proposal owners will generate the keys in Infrastructure and get them deployed to the sign vaults, and enable the configuration options for this in robosignatory.<br />
Support for file signatures is already in the deployed versions of sigul and robosignatory.<br />
<br />
* Other developers:<br />
Nothing needed from other developers<br />
<br />
* Release engineering: <br />
A mass rebuild would be nice (as it ensures all packages are signed), but is not required to implement the change itself.<br />
<br />
* Policies and guidelines:<br />
No impact<br />
<br />
* Trademark approval: <br />
No impact<br />
<br />
* Alignment with Objectives: <br />
This aligns with the Internet of Things objective.<br />
<br />
== Upgrade/compatibility impact ==<br />
For standard Fedora users there will be a very tiny increase in rpmdb size. If an advanced user was already signing their own files (for the Fedora shipped RPMs) for IMA functionality, they will just overwrite the existing signature.<br />
<br />
== How To Test ==<br />
You can verify that a signature has been put in place by looking at the extended attribute by running: `getfattr -d -m security.ima /usr/bin/bash` (change `/usr/bin/bash` with the file to check).<br />
<br />
The signatures can be tested “in vitro” by running `evmctl ima_verify --key publiccert.der -v myfile.txt`.<br />
This should result in the system reporting “<filename>: verification is OK”.<br />
The full system could be tested by enrolling the Fedora IMA key to the kernel `_ima` keyring, and adding a policy that verifies (some) files to be verified against the key. (instructions to follow).<br />
<br />
== User Experience ==<br />
If the user deploys an IMA policy to verify all or some files, they should be able to trust the signatures made by the Fedora build system.<br />
<br />
== Dependencies ==<br />
No external package dependencies.<br />
<br />
== Contingency Plan ==<br />
<br />
* Contingency mechanism: If the change is not finished in time, we have probably not yet started signing new files. Signing can easily be disabled by updating the config file should issues arise.<br />
If we did start signing, but haven’t signed everything, that is okay, since then packages will get signed as they’re bumped by developers, and they’ll be all signed in the next major release.<br />
<br />
* Contingency deadline: We could ship with this feature in an unfinished state.<br />
* Blocks release? No<br />
* Blocks product? N/A<br />
<br />
== Documentation ==<br />
We intend to write documentation on how to use the IMA subsystem for docs.fedoraproject.org, but that is parallel to this feature itself.<br />
We expect to provide example policies users can use to base their policy on.<br />
<br />
== Release Notes ==</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Changes/Signed_RPM_Contents&diff=601323Changes/Signed RPM Contents2021-01-20T23:22:29Z<p>Puiterwijk: /* Scope */</p>
<hr />
<div>= Signed RPM Contents =<br />
<br />
== Summary ==<br />
We want to add signatures to individual files that are part of shipped RPMs.<br />
These signatures will use the Linux IMA (Integrity Measurement Architecture) scheme, which means they can be used to enforce runtime policies to ensure execution of only trusted files.<br />
<br />
== Owner ==<br />
* Name: [[User:Puiterwijk| Patrick Uiterwijk]]<br />
* Email: puiterwijk@redhat.com<br />
* Name: [[User:Pbrobinson| Peter Robinson]]<br />
* Email: pbrobinson@gmail.com<br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<br />
== Current status ==<br />
[[Category:ChangeReadyforFesco]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
[[Category:SystemWideChange]]<br />
<br />
* Targeted release: [[Releases/34 | Fedora 34 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
ASSIGNED -> accepted by FESCo with ongoing development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* FESCo issue: [https://pagure.io/fesco/issue/2547 #2547]<br />
* Tracker bug: <will be assigned by the Wrangler><br />
* Release notes tracker: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
During signing builds, the files in it will be signed with IMA signatures.<br />
These signatures will be made with a key that’s kept by the Fedora Infrastructure team, and installed on the sign vaults.<br />
<br />
These signature can then be used with the Linux Integrity Measurement Architecture (IMA) kernel subsystem to verify files on execution based on a policy.<br />
<br />
The IMA subsystem is described on [https://sourceforge.net/p/linux-ima/wiki/Home/ the project page].<br />
<br />
IMA allows users to extend the trust of their system to the OS and processes.<br />
This means that they can configure a policy based on which the kernel will determine whether to verify (or measure) files before opening them.<br />
You could for example make a policy that appraises (verifies) all files that are executed by root: `appraise uid=1000 appraise_type=imasig`.<br />
<br />
Note explicitly that we do not intend to install a default policy as part of this change, and users will need to deploy their own policy before anything is measured or appraised.<br />
This means that after this is done, users will have the option to enable a policy and have that be enforced, but there will be nothing automatic.<br />
We will, however, document various example policies people can adapt to their needs.<br />
<br />
By default, the signatures will not be deployed to the file system. That will only be done once rpm-plugin-ima is installed.<br />
After that, RPM will put the signatures on the "security.ima" extended attribute on the files.<br />
<br />
== Feedback ==<br />
<br />
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. --><br />
<br />
<br />
=== RPM Size ===<br />
One of the main concerns that have been voiced is the RPM size, both on disk (mirrors) and on an installed system.<br />
For this comparison, I have cached all the RPMs installed in a Fedora Rawhide 20210118.n.1 default Server install (server netinstall disk, and then no changed to the group selection).<br />
After creating two copies of that data, one with just resigned (to exclude rpm size difference resulting from different key lengths), and one resigned with IMA file signatures inserted, I then installed two blank VMs by using the standard virt-manager settings, changing only the name and the system type to "EFI".<br />
<br />
This is using a prime256v1 file signing key. This is the same key format supported by the Fedora signing system.<br />
<br />
==== Binary RPMs on disk ====<br />
Resigned: 462524 (452M)<br />
<br />
Resigned+IMA: 467812 (457M)<br />
<br />
This comes down to a 1.1% increase on size of the binary RPMs.<br />
<br />
<br />
==== Installed size ====<br />
On installation of two different VMs, one with the resigned RPMs, and one with the resigned+ima RPMs, the `/usr` directory size does not change at all (both are exactly 1417064 bytes).<br />
<br />
The size of the rpmdb increases from 22952 to 28416 bytes, a 20% increase.<br />
This is on an install size of 1.7GB in total, so this 5MB increase is a 0.3% size increase on the final installed system.<br />
<br />
Note that both of those VMs did not have rpm-plugins-ima installed, which means the file signatures are not put in place.<br />
<br />
When I install the rpm-plugin-ima, and run "dnf reinstall *", the `/usr` directory increases by 0.002% to 1417104.<br />
<br />
<br />
<br />
=== Tie-in to Secure Boot ===<br />
<br />
While using the IMA subsystem in combination with Secure Boot enables users to extend trust on the system out into the binaries executed, there is no requirement at all to use secure boot.<br />
This means that if you have Secure Boot enabled, that enables you to extend the trust, but if you don't want to use secure boot, that has no impact on the IMA subsystem.<br />
<br />
<br />
=== Why in the RPM header, instead of a side-package like -debuginfo? ===<br />
<br />
These signatures would need to get deployed as a filesystem extended attribute in order to be used by the IMA subsystem.<br />
While it is possible to generate the signatures as separate files in a side package, that means that RPM would then need to add code to install extended attributes based on contents of another RPM package.<br />
This would mean that the contents of an e.g. `-file-signature` subpackage won't be deployed to the file systems as normal files, but instead as xattr's on existing files.<br />
<br />
That, together with the minimal size increases of the actual RPMs, made us decide to go with the signature header approach and not implement the side-package method.<br />
<br />
<br />
=== Comparison with MAC's ===<br />
<br />
The IMA subsystem is orthogonal to the Mandatory Access Control systems like selinux, though it is integrated with them.<br />
<br />
Where with selinux you can limit who can read from or write to to which file, IMA will allow you to set policies that enforce file contents to be as expected (signature validated) before they can be read/executed.<br />
<br />
The integration is in the form that you can write a policy line that matches on certain selinux contexts, like for example `dont_appraise obj_type=var_log_t`, to ensure that files of `var_log_t` do not need to be verified, and `appraise obj_type=shell_exec_t` to ensure that any shell that is executed (e.g. bash) is signed with a trusted key.<br />
<br />
<br />
=== Why not ... ===<br />
<br />
==== fsverity ====<br />
<br />
As one of the fsverity maintainers has said on [https://lwn.net/Articles/842326/|LWN]: IMA and FS-Verity are not mutually exclusive, but at this moment IMA has a possibility to enforce a system-wide policy instead of needing the userspace binaries to check the signature status themselves.<br />
<br />
<br />
==== rpm -V ====<br />
<br />
rpm -V will tell you whether a file matches the digest that's in the RPM Database, but that is useful if you think a file might have been accidentally changed. If an attacker has the opportunity to change a file on the file system, it is very likely they could also update the RPM binary (or the rpmdb) to make it not report the change.<br />
<br />
IMA signatures will be able to identify the file to have been changed, and importantly also enable a policy which enforces the signatures, which means that if a change was made to a file that is matched by a policy, the kernel would actively refuse loading it, instead of depending on the administrator to check its validity with a known-good rpm database and binary.<br />
<br />
== Benefit to Fedora ==<br />
<br />
Having all files signed with a verifiable key means that system owners can use the kernel Integrity and Measurement Architecture (IMA) to enforce only verified files can be executed, or define other policies.<br />
<br />
Having all files signed with Fedora keys would enable integration with for example [https://keylime.dev/|Keylime], which is a CNCF project that implements remote system attestation, based on which a system may or may not get access to secrets and other consequences.<br />
<br />
This feature is wanted by the IoT Edition, for enabling both attestation and local policy verification.<br />
<br />
== Scope ==<br />
* Proposal owners:<br />
The proposal owners will generate the keys in Infrastructure and get them deployed to the sign vaults, and enable the configuration options for this in robosignatory.<br />
Support for file signatures is already in the deployed versions of sigul and robosignatory.<br />
<br />
* Other developers:<br />
Nothing needed from other developers<br />
<br />
* Release engineering: <br />
A mass rebuild would be nice (as it ensures all packages are signed), but is not required to implement the change itself.<br />
<br />
* Policies and guidelines:<br />
No impact<br />
<br />
* Trademark approval: <br />
No impact<br />
<br />
* Alignment with Objectives: <br />
This aligns with the Internet of Things objective.<br />
<br />
== Upgrade/compatibility impact ==<br />
For standard Fedora users there will be a very tiny increase in rpmdb size. If an advanced user was already signing their own files (for the Fedora shipped RPMs) for IMA functionality, they will just overwrite the existing signature.<br />
<br />
== How To Test ==<br />
You can verify that a signature has been put in place by looking at the extended attribute by running: `getfattr -d -m security.ima /usr/bin/bash` (change `/usr/bin/bash` with the file to check).<br />
<br />
The signatures can be tested “in vitro” by running `evmctl ima_verify --key publiccert.der -v myfile.txt`.<br />
This should result in the system reporting “<filename>: verification is OK”.<br />
The full system could be tested by enrolling the Fedora IMA key to the kernel `_ima` keyring, and adding a policy that verifies (some) files to be verified against the key. (instructions to follow).<br />
<br />
== User Experience ==<br />
If the user deploys an IMA policy to verify all or some files, they should be able to trust the signatures made by the Fedora build system.<br />
<br />
== Dependencies ==<br />
No external package dependencies.<br />
<br />
== Contingency Plan ==<br />
<br />
* Contingency mechanism: If the change is not finished in time, we have probably not yet started signing new files. Signing can easily be disabled by updating the config file should issues arise.<br />
If we did start signing, but haven’t signed everything, that is okay, since then packages will get signed as they’re bumped by developers, and they’ll be all signed in the next major release.<br />
<br />
* Contingency deadline: We could ship with this feature in an unfinished state.<br />
* Blocks release? No<br />
* Blocks product? N/A<br />
<br />
== Documentation ==<br />
We intend to write documentation on how to use the IMA subsystem for docs.fedoraproject.org, but that is parallel to this feature itself.<br />
We expect to provide example policies users can use to base their policy on.<br />
<br />
== Release Notes ==</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Changes/Signed_RPM_Contents&diff=601322Changes/Signed RPM Contents2021-01-20T23:19:06Z<p>Puiterwijk: /* Upgrade/compatibility impact */</p>
<hr />
<div>= Signed RPM Contents =<br />
<br />
== Summary ==<br />
We want to add signatures to individual files that are part of shipped RPMs.<br />
These signatures will use the Linux IMA (Integrity Measurement Architecture) scheme, which means they can be used to enforce runtime policies to ensure execution of only trusted files.<br />
<br />
== Owner ==<br />
* Name: [[User:Puiterwijk| Patrick Uiterwijk]]<br />
* Email: puiterwijk@redhat.com<br />
* Name: [[User:Pbrobinson| Peter Robinson]]<br />
* Email: pbrobinson@gmail.com<br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<br />
== Current status ==<br />
[[Category:ChangeReadyforFesco]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
[[Category:SystemWideChange]]<br />
<br />
* Targeted release: [[Releases/34 | Fedora 34 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
ASSIGNED -> accepted by FESCo with ongoing development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* FESCo issue: [https://pagure.io/fesco/issue/2547 #2547]<br />
* Tracker bug: <will be assigned by the Wrangler><br />
* Release notes tracker: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
During signing builds, the files in it will be signed with IMA signatures.<br />
These signatures will be made with a key that’s kept by the Fedora Infrastructure team, and installed on the sign vaults.<br />
<br />
These signature can then be used with the Linux Integrity Measurement Architecture (IMA) kernel subsystem to verify files on execution based on a policy.<br />
<br />
The IMA subsystem is described on [https://sourceforge.net/p/linux-ima/wiki/Home/ the project page].<br />
<br />
IMA allows users to extend the trust of their system to the OS and processes.<br />
This means that they can configure a policy based on which the kernel will determine whether to verify (or measure) files before opening them.<br />
You could for example make a policy that appraises (verifies) all files that are executed by root: `appraise uid=1000 appraise_type=imasig`.<br />
<br />
Note explicitly that we do not intend to install a default policy as part of this change, and users will need to deploy their own policy before anything is measured or appraised.<br />
This means that after this is done, users will have the option to enable a policy and have that be enforced, but there will be nothing automatic.<br />
We will, however, document various example policies people can adapt to their needs.<br />
<br />
By default, the signatures will not be deployed to the file system. That will only be done once rpm-plugin-ima is installed.<br />
After that, RPM will put the signatures on the "security.ima" extended attribute on the files.<br />
<br />
== Feedback ==<br />
<br />
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. --><br />
<br />
<br />
=== RPM Size ===<br />
One of the main concerns that have been voiced is the RPM size, both on disk (mirrors) and on an installed system.<br />
For this comparison, I have cached all the RPMs installed in a Fedora Rawhide 20210118.n.1 default Server install (server netinstall disk, and then no changed to the group selection).<br />
After creating two copies of that data, one with just resigned (to exclude rpm size difference resulting from different key lengths), and one resigned with IMA file signatures inserted, I then installed two blank VMs by using the standard virt-manager settings, changing only the name and the system type to "EFI".<br />
<br />
This is using a prime256v1 file signing key. This is the same key format supported by the Fedora signing system.<br />
<br />
==== Binary RPMs on disk ====<br />
Resigned: 462524 (452M)<br />
<br />
Resigned+IMA: 467812 (457M)<br />
<br />
This comes down to a 1.1% increase on size of the binary RPMs.<br />
<br />
<br />
==== Installed size ====<br />
On installation of two different VMs, one with the resigned RPMs, and one with the resigned+ima RPMs, the `/usr` directory size does not change at all (both are exactly 1417064 bytes).<br />
<br />
The size of the rpmdb increases from 22952 to 28416 bytes, a 20% increase.<br />
This is on an install size of 1.7GB in total, so this 5MB increase is a 0.3% size increase on the final installed system.<br />
<br />
Note that both of those VMs did not have rpm-plugins-ima installed, which means the file signatures are not put in place.<br />
<br />
When I install the rpm-plugin-ima, and run "dnf reinstall *", the `/usr` directory increases by 0.002% to 1417104.<br />
<br />
<br />
<br />
=== Tie-in to Secure Boot ===<br />
<br />
While using the IMA subsystem in combination with Secure Boot enables users to extend trust on the system out into the binaries executed, there is no requirement at all to use secure boot.<br />
This means that if you have Secure Boot enabled, that enables you to extend the trust, but if you don't want to use secure boot, that has no impact on the IMA subsystem.<br />
<br />
<br />
=== Why in the RPM header, instead of a side-package like -debuginfo? ===<br />
<br />
These signatures would need to get deployed as a filesystem extended attribute in order to be used by the IMA subsystem.<br />
While it is possible to generate the signatures as separate files in a side package, that means that RPM would then need to add code to install extended attributes based on contents of another RPM package.<br />
This would mean that the contents of an e.g. `-file-signature` subpackage won't be deployed to the file systems as normal files, but instead as xattr's on existing files.<br />
<br />
That, together with the minimal size increases of the actual RPMs, made us decide to go with the signature header approach and not implement the side-package method.<br />
<br />
<br />
=== Comparison with MAC's ===<br />
<br />
The IMA subsystem is orthogonal to the Mandatory Access Control systems like selinux, though it is integrated with them.<br />
<br />
Where with selinux you can limit who can read from or write to to which file, IMA will allow you to set policies that enforce file contents to be as expected (signature validated) before they can be read/executed.<br />
<br />
The integration is in the form that you can write a policy line that matches on certain selinux contexts, like for example `dont_appraise obj_type=var_log_t`, to ensure that files of `var_log_t` do not need to be verified, and `appraise obj_type=shell_exec_t` to ensure that any shell that is executed (e.g. bash) is signed with a trusted key.<br />
<br />
<br />
=== Why not ... ===<br />
<br />
==== fsverity ====<br />
<br />
As one of the fsverity maintainers has said on [https://lwn.net/Articles/842326/|LWN]: IMA and FS-Verity are not mutually exclusive, but at this moment IMA has a possibility to enforce a system-wide policy instead of needing the userspace binaries to check the signature status themselves.<br />
<br />
<br />
==== rpm -V ====<br />
<br />
rpm -V will tell you whether a file matches the digest that's in the RPM Database, but that is useful if you think a file might have been accidentally changed. If an attacker has the opportunity to change a file on the file system, it is very likely they could also update the RPM binary (or the rpmdb) to make it not report the change.<br />
<br />
IMA signatures will be able to identify the file to have been changed, and importantly also enable a policy which enforces the signatures, which means that if a change was made to a file that is matched by a policy, the kernel would actively refuse loading it, instead of depending on the administrator to check its validity with a known-good rpm database and binary.<br />
<br />
== Benefit to Fedora ==<br />
<br />
Having all files signed with a verifiable key means that system owners can use the kernel Integrity and Measurement Architecture (IMA) to enforce only verified files can be executed, or define other policies.<br />
<br />
Having all files signed with Fedora keys would enable integration with for example [https://keylime.dev/|Keylime], which is a CNCF project that implements remote system attestation, based on which a system may or may not get access to secrets and other consequences.<br />
<br />
This feature is wanted by the IoT Edition, for enabling both attestation and local policy verification.<br />
<br />
== Scope ==<br />
* Proposal owners:<br />
The proposal owners will write the code for sigul to pass the required arguments, generate the keys in Infrastructure and get them deployed to the sign vaults.<br />
<br />
* Other developers:<br />
Nothing needed from other developers<br />
<br />
* Release engineering: <br />
A mass rebuild would be nice (as it ensures all packages are signed), but is not required to implement the change itself.<br />
<br />
* Policies and guidelines:<br />
No impact<br />
<br />
* Trademark approval: <br />
No impact<br />
<br />
* Alignment with Objectives: <br />
This aligns with the Internet of Things objective.<br />
<br />
== Upgrade/compatibility impact ==<br />
For standard Fedora users there will be a very tiny increase in rpmdb size. If an advanced user was already signing their own files (for the Fedora shipped RPMs) for IMA functionality, they will just overwrite the existing signature.<br />
<br />
== How To Test ==<br />
You can verify that a signature has been put in place by looking at the extended attribute by running: `getfattr -d -m security.ima /usr/bin/bash` (change `/usr/bin/bash` with the file to check).<br />
<br />
The signatures can be tested “in vitro” by running `evmctl ima_verify --key publiccert.der -v myfile.txt`.<br />
This should result in the system reporting “<filename>: verification is OK”.<br />
The full system could be tested by enrolling the Fedora IMA key to the kernel `_ima` keyring, and adding a policy that verifies (some) files to be verified against the key. (instructions to follow).<br />
<br />
== User Experience ==<br />
If the user deploys an IMA policy to verify all or some files, they should be able to trust the signatures made by the Fedora build system.<br />
<br />
== Dependencies ==<br />
No external package dependencies.<br />
<br />
== Contingency Plan ==<br />
<br />
* Contingency mechanism: If the change is not finished in time, we have probably not yet started signing new files. Signing can easily be disabled by updating the config file should issues arise.<br />
If we did start signing, but haven’t signed everything, that is okay, since then packages will get signed as they’re bumped by developers, and they’ll be all signed in the next major release.<br />
<br />
* Contingency deadline: We could ship with this feature in an unfinished state.<br />
* Blocks release? No<br />
* Blocks product? N/A<br />
<br />
== Documentation ==<br />
We intend to write documentation on how to use the IMA subsystem for docs.fedoraproject.org, but that is parallel to this feature itself.<br />
We expect to provide example policies users can use to base their policy on.<br />
<br />
== Release Notes ==</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Changes/Signed_RPM_Contents&diff=601321Changes/Signed RPM Contents2021-01-20T23:18:28Z<p>Puiterwijk: /* Feedback */</p>
<hr />
<div>= Signed RPM Contents =<br />
<br />
== Summary ==<br />
We want to add signatures to individual files that are part of shipped RPMs.<br />
These signatures will use the Linux IMA (Integrity Measurement Architecture) scheme, which means they can be used to enforce runtime policies to ensure execution of only trusted files.<br />
<br />
== Owner ==<br />
* Name: [[User:Puiterwijk| Patrick Uiterwijk]]<br />
* Email: puiterwijk@redhat.com<br />
* Name: [[User:Pbrobinson| Peter Robinson]]<br />
* Email: pbrobinson@gmail.com<br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<br />
== Current status ==<br />
[[Category:ChangeReadyforFesco]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
[[Category:SystemWideChange]]<br />
<br />
* Targeted release: [[Releases/34 | Fedora 34 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
ASSIGNED -> accepted by FESCo with ongoing development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* FESCo issue: [https://pagure.io/fesco/issue/2547 #2547]<br />
* Tracker bug: <will be assigned by the Wrangler><br />
* Release notes tracker: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
During signing builds, the files in it will be signed with IMA signatures.<br />
These signatures will be made with a key that’s kept by the Fedora Infrastructure team, and installed on the sign vaults.<br />
<br />
These signature can then be used with the Linux Integrity Measurement Architecture (IMA) kernel subsystem to verify files on execution based on a policy.<br />
<br />
The IMA subsystem is described on [https://sourceforge.net/p/linux-ima/wiki/Home/ the project page].<br />
<br />
IMA allows users to extend the trust of their system to the OS and processes.<br />
This means that they can configure a policy based on which the kernel will determine whether to verify (or measure) files before opening them.<br />
You could for example make a policy that appraises (verifies) all files that are executed by root: `appraise uid=1000 appraise_type=imasig`.<br />
<br />
Note explicitly that we do not intend to install a default policy as part of this change, and users will need to deploy their own policy before anything is measured or appraised.<br />
This means that after this is done, users will have the option to enable a policy and have that be enforced, but there will be nothing automatic.<br />
We will, however, document various example policies people can adapt to their needs.<br />
<br />
By default, the signatures will not be deployed to the file system. That will only be done once rpm-plugin-ima is installed.<br />
After that, RPM will put the signatures on the "security.ima" extended attribute on the files.<br />
<br />
== Feedback ==<br />
<br />
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. --><br />
<br />
<br />
=== RPM Size ===<br />
One of the main concerns that have been voiced is the RPM size, both on disk (mirrors) and on an installed system.<br />
For this comparison, I have cached all the RPMs installed in a Fedora Rawhide 20210118.n.1 default Server install (server netinstall disk, and then no changed to the group selection).<br />
After creating two copies of that data, one with just resigned (to exclude rpm size difference resulting from different key lengths), and one resigned with IMA file signatures inserted, I then installed two blank VMs by using the standard virt-manager settings, changing only the name and the system type to "EFI".<br />
<br />
This is using a prime256v1 file signing key. This is the same key format supported by the Fedora signing system.<br />
<br />
==== Binary RPMs on disk ====<br />
Resigned: 462524 (452M)<br />
<br />
Resigned+IMA: 467812 (457M)<br />
<br />
This comes down to a 1.1% increase on size of the binary RPMs.<br />
<br />
<br />
==== Installed size ====<br />
On installation of two different VMs, one with the resigned RPMs, and one with the resigned+ima RPMs, the `/usr` directory size does not change at all (both are exactly 1417064 bytes).<br />
<br />
The size of the rpmdb increases from 22952 to 28416 bytes, a 20% increase.<br />
This is on an install size of 1.7GB in total, so this 5MB increase is a 0.3% size increase on the final installed system.<br />
<br />
Note that both of those VMs did not have rpm-plugins-ima installed, which means the file signatures are not put in place.<br />
<br />
When I install the rpm-plugin-ima, and run "dnf reinstall *", the `/usr` directory increases by 0.002% to 1417104.<br />
<br />
<br />
<br />
=== Tie-in to Secure Boot ===<br />
<br />
While using the IMA subsystem in combination with Secure Boot enables users to extend trust on the system out into the binaries executed, there is no requirement at all to use secure boot.<br />
This means that if you have Secure Boot enabled, that enables you to extend the trust, but if you don't want to use secure boot, that has no impact on the IMA subsystem.<br />
<br />
<br />
=== Why in the RPM header, instead of a side-package like -debuginfo? ===<br />
<br />
These signatures would need to get deployed as a filesystem extended attribute in order to be used by the IMA subsystem.<br />
While it is possible to generate the signatures as separate files in a side package, that means that RPM would then need to add code to install extended attributes based on contents of another RPM package.<br />
This would mean that the contents of an e.g. `-file-signature` subpackage won't be deployed to the file systems as normal files, but instead as xattr's on existing files.<br />
<br />
That, together with the minimal size increases of the actual RPMs, made us decide to go with the signature header approach and not implement the side-package method.<br />
<br />
<br />
=== Comparison with MAC's ===<br />
<br />
The IMA subsystem is orthogonal to the Mandatory Access Control systems like selinux, though it is integrated with them.<br />
<br />
Where with selinux you can limit who can read from or write to to which file, IMA will allow you to set policies that enforce file contents to be as expected (signature validated) before they can be read/executed.<br />
<br />
The integration is in the form that you can write a policy line that matches on certain selinux contexts, like for example `dont_appraise obj_type=var_log_t`, to ensure that files of `var_log_t` do not need to be verified, and `appraise obj_type=shell_exec_t` to ensure that any shell that is executed (e.g. bash) is signed with a trusted key.<br />
<br />
<br />
=== Why not ... ===<br />
<br />
==== fsverity ====<br />
<br />
As one of the fsverity maintainers has said on [https://lwn.net/Articles/842326/|LWN]: IMA and FS-Verity are not mutually exclusive, but at this moment IMA has a possibility to enforce a system-wide policy instead of needing the userspace binaries to check the signature status themselves.<br />
<br />
<br />
==== rpm -V ====<br />
<br />
rpm -V will tell you whether a file matches the digest that's in the RPM Database, but that is useful if you think a file might have been accidentally changed. If an attacker has the opportunity to change a file on the file system, it is very likely they could also update the RPM binary (or the rpmdb) to make it not report the change.<br />
<br />
IMA signatures will be able to identify the file to have been changed, and importantly also enable a policy which enforces the signatures, which means that if a change was made to a file that is matched by a policy, the kernel would actively refuse loading it, instead of depending on the administrator to check its validity with a known-good rpm database and binary.<br />
<br />
== Benefit to Fedora ==<br />
<br />
Having all files signed with a verifiable key means that system owners can use the kernel Integrity and Measurement Architecture (IMA) to enforce only verified files can be executed, or define other policies.<br />
<br />
Having all files signed with Fedora keys would enable integration with for example [https://keylime.dev/|Keylime], which is a CNCF project that implements remote system attestation, based on which a system may or may not get access to secrets and other consequences.<br />
<br />
This feature is wanted by the IoT Edition, for enabling both attestation and local policy verification.<br />
<br />
== Scope ==<br />
* Proposal owners:<br />
The proposal owners will write the code for sigul to pass the required arguments, generate the keys in Infrastructure and get them deployed to the sign vaults.<br />
<br />
* Other developers:<br />
Nothing needed from other developers<br />
<br />
* Release engineering: <br />
A mass rebuild would be nice (as it ensures all packages are signed), but is not required to implement the change itself.<br />
<br />
* Policies and guidelines:<br />
No impact<br />
<br />
* Trademark approval: <br />
No impact<br />
<br />
* Alignment with Objectives: <br />
This aligns with the Internet of Things objective.<br />
<br />
== Upgrade/compatibility impact ==<br />
For standard Fedora users there will be no impact. If an advanced user was already signing their own files (for the Fedora shipped RPMs) for IMA functionality, they will just overwrite the existing signature.<br />
<br />
== How To Test ==<br />
You can verify that a signature has been put in place by looking at the extended attribute by running: `getfattr -d -m security.ima /usr/bin/bash` (change `/usr/bin/bash` with the file to check).<br />
<br />
The signatures can be tested “in vitro” by running `evmctl ima_verify --key publiccert.der -v myfile.txt`.<br />
This should result in the system reporting “<filename>: verification is OK”.<br />
The full system could be tested by enrolling the Fedora IMA key to the kernel `_ima` keyring, and adding a policy that verifies (some) files to be verified against the key. (instructions to follow).<br />
<br />
== User Experience ==<br />
If the user deploys an IMA policy to verify all or some files, they should be able to trust the signatures made by the Fedora build system.<br />
<br />
== Dependencies ==<br />
No external package dependencies.<br />
<br />
== Contingency Plan ==<br />
<br />
* Contingency mechanism: If the change is not finished in time, we have probably not yet started signing new files. Signing can easily be disabled by updating the config file should issues arise.<br />
If we did start signing, but haven’t signed everything, that is okay, since then packages will get signed as they’re bumped by developers, and they’ll be all signed in the next major release.<br />
<br />
* Contingency deadline: We could ship with this feature in an unfinished state.<br />
* Blocks release? No<br />
* Blocks product? N/A<br />
<br />
== Documentation ==<br />
We intend to write documentation on how to use the IMA subsystem for docs.fedoraproject.org, but that is parallel to this feature itself.<br />
We expect to provide example policies users can use to base their policy on.<br />
<br />
== Release Notes ==</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Changes/Signed_RPM_Contents&diff=601320Changes/Signed RPM Contents2021-01-20T23:07:31Z<p>Puiterwijk: /* How To Test */</p>
<hr />
<div>= Signed RPM Contents =<br />
<br />
== Summary ==<br />
We want to add signatures to individual files that are part of shipped RPMs.<br />
These signatures will use the Linux IMA (Integrity Measurement Architecture) scheme, which means they can be used to enforce runtime policies to ensure execution of only trusted files.<br />
<br />
== Owner ==<br />
* Name: [[User:Puiterwijk| Patrick Uiterwijk]]<br />
* Email: puiterwijk@redhat.com<br />
* Name: [[User:Pbrobinson| Peter Robinson]]<br />
* Email: pbrobinson@gmail.com<br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<br />
== Current status ==<br />
[[Category:ChangeReadyforFesco]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
[[Category:SystemWideChange]]<br />
<br />
* Targeted release: [[Releases/34 | Fedora 34 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
ASSIGNED -> accepted by FESCo with ongoing development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* FESCo issue: [https://pagure.io/fesco/issue/2547 #2547]<br />
* Tracker bug: <will be assigned by the Wrangler><br />
* Release notes tracker: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
During signing builds, the files in it will be signed with IMA signatures.<br />
These signatures will be made with a key that’s kept by the Fedora Infrastructure team, and installed on the sign vaults.<br />
<br />
These signature can then be used with the Linux Integrity Measurement Architecture (IMA) kernel subsystem to verify files on execution based on a policy.<br />
<br />
The IMA subsystem is described on [https://sourceforge.net/p/linux-ima/wiki/Home/ the project page].<br />
<br />
IMA allows users to extend the trust of their system to the OS and processes.<br />
This means that they can configure a policy based on which the kernel will determine whether to verify (or measure) files before opening them.<br />
You could for example make a policy that appraises (verifies) all files that are executed by root: `appraise uid=1000 appraise_type=imasig`.<br />
<br />
Note explicitly that we do not intend to install a default policy as part of this change, and users will need to deploy their own policy before anything is measured or appraised.<br />
This means that after this is done, users will have the option to enable a policy and have that be enforced, but there will be nothing automatic.<br />
We will, however, document various example policies people can adapt to their needs.<br />
<br />
By default, the signatures will not be deployed to the file system. That will only be done once rpm-plugin-ima is installed.<br />
After that, RPM will put the signatures on the "security.ima" extended attribute on the files.<br />
<br />
== Feedback ==<br />
<br />
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. --><br />
<br />
<br />
=== RPM Size ===<br />
One of the main concerns that have been voiced is the RPM size, both on disk (mirrors) and on an installed system.<br />
For this comparison, I have cached all the RPMs installed in a Fedora Rawhide 20210118.n.1 default Server install (server netinstall disk, and then no changed to the group selection).<br />
After creating two copies of that data, one with just resigned (to exclude rpm size difference resulting from different key lengths), and one resigned with IMA file signatures inserted, I then installed two blank VMs by using the standard virt-manager settings, changing only the name and the system type to "EFI".<br />
<br />
This is using a prime256v1 file signing key. This is the same key format supported by the Fedora signing system.<br />
<br />
==== Binary RPMs on disk ====<br />
Resigned: 462524 (452M)<br />
<br />
Resigned+IMA: 467812 (457M)<br />
<br />
This comes down to a 1.1% increase on size of the binary RPMs.<br />
<br />
<br />
==== Installed size ====<br />
On installation of two different VMs, one with the resigned RPMs, and one with the resigned+ima RPMs, the `/usr` directory size does not change at all (both are exactly 1417064 bytes).<br />
<br />
The size of the rpmdb increases from 22952 to 28416 bytes, a 20% increase.<br />
This is on an install size of 1.7GB in total, so this 5MB increase is a 0.3% size increase on the final installed system.<br />
<br />
Note that both of those VMs did not have rpm-plugins-ima installed, which means the file signatures are not put in place.<br />
<br />
When I install the rpm-plugin-ima, and run "dnf reinstall *", the `/usr` directory increases by 0.002% to 1417104.<br />
<br />
<br />
<br />
=== Tie-in to Secure Boot ===<br />
<br />
While using the IMA subsystem in combination with Secure Boot enables users to extend trust on the system out into the binaries executed, there is no requirement at all to use secure boot.<br />
This means that if you have Secure Boot enabled, that enables you to extend the trust, but if you don't want to use secure boot, that has no impact on the IMA subsystem.<br />
<br />
<br />
=== Why in the RPM header, instead of a side-package like -debuginfo? ===<br />
<br />
These signatures would need to get deployed as a filesystem extended attribute in order to be used by the IMA subsystem.<br />
While it is possible to generate the signatures as separate files in a side package, that means that RPM would then need to add code to install extended attributes based on contents of another RPM package.<br />
This would mean that the contents of an e.g. `-file-signature` subpackage won't be deployed to the file systems as normal files, but instead as xattr's on existing files.<br />
<br />
That, together with the minimal size increases of the actual RPMs, made us decide to go with the signature header approach and not implement the side-package method.<br />
<br />
<br />
=== Comparison with MAC's ===<br />
<br />
The IMA subsystem is orthogonal to the Mandatory Access Control systems like selinux, though it is integrated with them.<br />
<br />
Where with selinux you can limit who can read from or write to to which file, IMA will allow you to set policies that enforce file contents to be as expected (signature validated) before they can be read/executed.<br />
<br />
The integration is in the form that you can write a policy line that matches on certain selinux contexts, like for example `dont_appraise obj_type=var_log_t`, to ensure that files of `var_log_t` do not need to be verified, and `appraise obj_type=shell_exec_t` to ensure that any shell that is executed (e.g. bash) is signed with a trusted key.<br />
<br />
== Benefit to Fedora ==<br />
<br />
Having all files signed with a verifiable key means that system owners can use the kernel Integrity and Measurement Architecture (IMA) to enforce only verified files can be executed, or define other policies.<br />
<br />
Having all files signed with Fedora keys would enable integration with for example [https://keylime.dev/|Keylime], which is a CNCF project that implements remote system attestation, based on which a system may or may not get access to secrets and other consequences.<br />
<br />
This feature is wanted by the IoT Edition, for enabling both attestation and local policy verification.<br />
<br />
== Scope ==<br />
* Proposal owners:<br />
The proposal owners will write the code for sigul to pass the required arguments, generate the keys in Infrastructure and get them deployed to the sign vaults.<br />
<br />
* Other developers:<br />
Nothing needed from other developers<br />
<br />
* Release engineering: <br />
A mass rebuild would be nice (as it ensures all packages are signed), but is not required to implement the change itself.<br />
<br />
* Policies and guidelines:<br />
No impact<br />
<br />
* Trademark approval: <br />
No impact<br />
<br />
* Alignment with Objectives: <br />
This aligns with the Internet of Things objective.<br />
<br />
== Upgrade/compatibility impact ==<br />
For standard Fedora users there will be no impact. If an advanced user was already signing their own files (for the Fedora shipped RPMs) for IMA functionality, they will just overwrite the existing signature.<br />
<br />
== How To Test ==<br />
You can verify that a signature has been put in place by looking at the extended attribute by running: `getfattr -d -m security.ima /usr/bin/bash` (change `/usr/bin/bash` with the file to check).<br />
<br />
The signatures can be tested “in vitro” by running `evmctl ima_verify --key publiccert.der -v myfile.txt`.<br />
This should result in the system reporting “<filename>: verification is OK”.<br />
The full system could be tested by enrolling the Fedora IMA key to the kernel `_ima` keyring, and adding a policy that verifies (some) files to be verified against the key. (instructions to follow).<br />
<br />
== User Experience ==<br />
If the user deploys an IMA policy to verify all or some files, they should be able to trust the signatures made by the Fedora build system.<br />
<br />
== Dependencies ==<br />
No external package dependencies.<br />
<br />
== Contingency Plan ==<br />
<br />
* Contingency mechanism: If the change is not finished in time, we have probably not yet started signing new files. Signing can easily be disabled by updating the config file should issues arise.<br />
If we did start signing, but haven’t signed everything, that is okay, since then packages will get signed as they’re bumped by developers, and they’ll be all signed in the next major release.<br />
<br />
* Contingency deadline: We could ship with this feature in an unfinished state.<br />
* Blocks release? No<br />
* Blocks product? N/A<br />
<br />
== Documentation ==<br />
We intend to write documentation on how to use the IMA subsystem for docs.fedoraproject.org, but that is parallel to this feature itself.<br />
We expect to provide example policies users can use to base their policy on.<br />
<br />
== Release Notes ==</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Changes/Signed_RPM_Contents&diff=601319Changes/Signed RPM Contents2021-01-20T23:06:31Z<p>Puiterwijk: /* Documentation */</p>
<hr />
<div>= Signed RPM Contents =<br />
<br />
== Summary ==<br />
We want to add signatures to individual files that are part of shipped RPMs.<br />
These signatures will use the Linux IMA (Integrity Measurement Architecture) scheme, which means they can be used to enforce runtime policies to ensure execution of only trusted files.<br />
<br />
== Owner ==<br />
* Name: [[User:Puiterwijk| Patrick Uiterwijk]]<br />
* Email: puiterwijk@redhat.com<br />
* Name: [[User:Pbrobinson| Peter Robinson]]<br />
* Email: pbrobinson@gmail.com<br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<br />
== Current status ==<br />
[[Category:ChangeReadyforFesco]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
[[Category:SystemWideChange]]<br />
<br />
* Targeted release: [[Releases/34 | Fedora 34 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
ASSIGNED -> accepted by FESCo with ongoing development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* FESCo issue: [https://pagure.io/fesco/issue/2547 #2547]<br />
* Tracker bug: <will be assigned by the Wrangler><br />
* Release notes tracker: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
During signing builds, the files in it will be signed with IMA signatures.<br />
These signatures will be made with a key that’s kept by the Fedora Infrastructure team, and installed on the sign vaults.<br />
<br />
These signature can then be used with the Linux Integrity Measurement Architecture (IMA) kernel subsystem to verify files on execution based on a policy.<br />
<br />
The IMA subsystem is described on [https://sourceforge.net/p/linux-ima/wiki/Home/ the project page].<br />
<br />
IMA allows users to extend the trust of their system to the OS and processes.<br />
This means that they can configure a policy based on which the kernel will determine whether to verify (or measure) files before opening them.<br />
You could for example make a policy that appraises (verifies) all files that are executed by root: `appraise uid=1000 appraise_type=imasig`.<br />
<br />
Note explicitly that we do not intend to install a default policy as part of this change, and users will need to deploy their own policy before anything is measured or appraised.<br />
This means that after this is done, users will have the option to enable a policy and have that be enforced, but there will be nothing automatic.<br />
We will, however, document various example policies people can adapt to their needs.<br />
<br />
By default, the signatures will not be deployed to the file system. That will only be done once rpm-plugin-ima is installed.<br />
After that, RPM will put the signatures on the "security.ima" extended attribute on the files.<br />
<br />
== Feedback ==<br />
<br />
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. --><br />
<br />
<br />
=== RPM Size ===<br />
One of the main concerns that have been voiced is the RPM size, both on disk (mirrors) and on an installed system.<br />
For this comparison, I have cached all the RPMs installed in a Fedora Rawhide 20210118.n.1 default Server install (server netinstall disk, and then no changed to the group selection).<br />
After creating two copies of that data, one with just resigned (to exclude rpm size difference resulting from different key lengths), and one resigned with IMA file signatures inserted, I then installed two blank VMs by using the standard virt-manager settings, changing only the name and the system type to "EFI".<br />
<br />
This is using a prime256v1 file signing key. This is the same key format supported by the Fedora signing system.<br />
<br />
==== Binary RPMs on disk ====<br />
Resigned: 462524 (452M)<br />
<br />
Resigned+IMA: 467812 (457M)<br />
<br />
This comes down to a 1.1% increase on size of the binary RPMs.<br />
<br />
<br />
==== Installed size ====<br />
On installation of two different VMs, one with the resigned RPMs, and one with the resigned+ima RPMs, the `/usr` directory size does not change at all (both are exactly 1417064 bytes).<br />
<br />
The size of the rpmdb increases from 22952 to 28416 bytes, a 20% increase.<br />
This is on an install size of 1.7GB in total, so this 5MB increase is a 0.3% size increase on the final installed system.<br />
<br />
Note that both of those VMs did not have rpm-plugins-ima installed, which means the file signatures are not put in place.<br />
<br />
When I install the rpm-plugin-ima, and run "dnf reinstall *", the `/usr` directory increases by 0.002% to 1417104.<br />
<br />
<br />
<br />
=== Tie-in to Secure Boot ===<br />
<br />
While using the IMA subsystem in combination with Secure Boot enables users to extend trust on the system out into the binaries executed, there is no requirement at all to use secure boot.<br />
This means that if you have Secure Boot enabled, that enables you to extend the trust, but if you don't want to use secure boot, that has no impact on the IMA subsystem.<br />
<br />
<br />
=== Why in the RPM header, instead of a side-package like -debuginfo? ===<br />
<br />
These signatures would need to get deployed as a filesystem extended attribute in order to be used by the IMA subsystem.<br />
While it is possible to generate the signatures as separate files in a side package, that means that RPM would then need to add code to install extended attributes based on contents of another RPM package.<br />
This would mean that the contents of an e.g. `-file-signature` subpackage won't be deployed to the file systems as normal files, but instead as xattr's on existing files.<br />
<br />
That, together with the minimal size increases of the actual RPMs, made us decide to go with the signature header approach and not implement the side-package method.<br />
<br />
<br />
=== Comparison with MAC's ===<br />
<br />
The IMA subsystem is orthogonal to the Mandatory Access Control systems like selinux, though it is integrated with them.<br />
<br />
Where with selinux you can limit who can read from or write to to which file, IMA will allow you to set policies that enforce file contents to be as expected (signature validated) before they can be read/executed.<br />
<br />
The integration is in the form that you can write a policy line that matches on certain selinux contexts, like for example `dont_appraise obj_type=var_log_t`, to ensure that files of `var_log_t` do not need to be verified, and `appraise obj_type=shell_exec_t` to ensure that any shell that is executed (e.g. bash) is signed with a trusted key.<br />
<br />
== Benefit to Fedora ==<br />
<br />
Having all files signed with a verifiable key means that system owners can use the kernel Integrity and Measurement Architecture (IMA) to enforce only verified files can be executed, or define other policies.<br />
<br />
Having all files signed with Fedora keys would enable integration with for example [https://keylime.dev/|Keylime], which is a CNCF project that implements remote system attestation, based on which a system may or may not get access to secrets and other consequences.<br />
<br />
This feature is wanted by the IoT Edition, for enabling both attestation and local policy verification.<br />
<br />
== Scope ==<br />
* Proposal owners:<br />
The proposal owners will write the code for sigul to pass the required arguments, generate the keys in Infrastructure and get them deployed to the sign vaults.<br />
<br />
* Other developers:<br />
Nothing needed from other developers<br />
<br />
* Release engineering: <br />
A mass rebuild would be nice (as it ensures all packages are signed), but is not required to implement the change itself.<br />
<br />
* Policies and guidelines:<br />
No impact<br />
<br />
* Trademark approval: <br />
No impact<br />
<br />
* Alignment with Objectives: <br />
This aligns with the Internet of Things objective.<br />
<br />
== Upgrade/compatibility impact ==<br />
For standard Fedora users there will be no impact. If an advanced user was already signing their own files (for the Fedora shipped RPMs) for IMA functionality, they will just overwrite the existing signature.<br />
<br />
== How To Test ==<br />
The signatures can be tested “in vitro” by running `evmctl ima_verify --sigfile --key publiccert.der -v myfile.txt`.<br />
This should result in the system reporting “<filename>: verification is OK”.<br />
The full system could be tested by enrolling the Fedora IMA key to the kernel `_ima` keyring, and adding a policy that verifies (some) files to be verified against the key. (instructions to follow).<br />
<br />
== User Experience ==<br />
If the user deploys an IMA policy to verify all or some files, they should be able to trust the signatures made by the Fedora build system.<br />
<br />
== Dependencies ==<br />
No external package dependencies.<br />
<br />
== Contingency Plan ==<br />
<br />
* Contingency mechanism: If the change is not finished in time, we have probably not yet started signing new files. Signing can easily be disabled by updating the config file should issues arise.<br />
If we did start signing, but haven’t signed everything, that is okay, since then packages will get signed as they’re bumped by developers, and they’ll be all signed in the next major release.<br />
<br />
* Contingency deadline: We could ship with this feature in an unfinished state.<br />
* Blocks release? No<br />
* Blocks product? N/A<br />
<br />
== Documentation ==<br />
We intend to write documentation on how to use the IMA subsystem for docs.fedoraproject.org, but that is parallel to this feature itself.<br />
We expect to provide example policies users can use to base their policy on.<br />
<br />
== Release Notes ==</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Changes/Signed_RPM_Contents&diff=601318Changes/Signed RPM Contents2021-01-20T23:06:06Z<p>Puiterwijk: /* Detailed Description */</p>
<hr />
<div>= Signed RPM Contents =<br />
<br />
== Summary ==<br />
We want to add signatures to individual files that are part of shipped RPMs.<br />
These signatures will use the Linux IMA (Integrity Measurement Architecture) scheme, which means they can be used to enforce runtime policies to ensure execution of only trusted files.<br />
<br />
== Owner ==<br />
* Name: [[User:Puiterwijk| Patrick Uiterwijk]]<br />
* Email: puiterwijk@redhat.com<br />
* Name: [[User:Pbrobinson| Peter Robinson]]<br />
* Email: pbrobinson@gmail.com<br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<br />
== Current status ==<br />
[[Category:ChangeReadyforFesco]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
[[Category:SystemWideChange]]<br />
<br />
* Targeted release: [[Releases/34 | Fedora 34 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
ASSIGNED -> accepted by FESCo with ongoing development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* FESCo issue: [https://pagure.io/fesco/issue/2547 #2547]<br />
* Tracker bug: <will be assigned by the Wrangler><br />
* Release notes tracker: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
During signing builds, the files in it will be signed with IMA signatures.<br />
These signatures will be made with a key that’s kept by the Fedora Infrastructure team, and installed on the sign vaults.<br />
<br />
These signature can then be used with the Linux Integrity Measurement Architecture (IMA) kernel subsystem to verify files on execution based on a policy.<br />
<br />
The IMA subsystem is described on [https://sourceforge.net/p/linux-ima/wiki/Home/ the project page].<br />
<br />
IMA allows users to extend the trust of their system to the OS and processes.<br />
This means that they can configure a policy based on which the kernel will determine whether to verify (or measure) files before opening them.<br />
You could for example make a policy that appraises (verifies) all files that are executed by root: `appraise uid=1000 appraise_type=imasig`.<br />
<br />
Note explicitly that we do not intend to install a default policy as part of this change, and users will need to deploy their own policy before anything is measured or appraised.<br />
This means that after this is done, users will have the option to enable a policy and have that be enforced, but there will be nothing automatic.<br />
We will, however, document various example policies people can adapt to their needs.<br />
<br />
By default, the signatures will not be deployed to the file system. That will only be done once rpm-plugin-ima is installed.<br />
After that, RPM will put the signatures on the "security.ima" extended attribute on the files.<br />
<br />
== Feedback ==<br />
<br />
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. --><br />
<br />
<br />
=== RPM Size ===<br />
One of the main concerns that have been voiced is the RPM size, both on disk (mirrors) and on an installed system.<br />
For this comparison, I have cached all the RPMs installed in a Fedora Rawhide 20210118.n.1 default Server install (server netinstall disk, and then no changed to the group selection).<br />
After creating two copies of that data, one with just resigned (to exclude rpm size difference resulting from different key lengths), and one resigned with IMA file signatures inserted, I then installed two blank VMs by using the standard virt-manager settings, changing only the name and the system type to "EFI".<br />
<br />
This is using a prime256v1 file signing key. This is the same key format supported by the Fedora signing system.<br />
<br />
==== Binary RPMs on disk ====<br />
Resigned: 462524 (452M)<br />
<br />
Resigned+IMA: 467812 (457M)<br />
<br />
This comes down to a 1.1% increase on size of the binary RPMs.<br />
<br />
<br />
==== Installed size ====<br />
On installation of two different VMs, one with the resigned RPMs, and one with the resigned+ima RPMs, the `/usr` directory size does not change at all (both are exactly 1417064 bytes).<br />
<br />
The size of the rpmdb increases from 22952 to 28416 bytes, a 20% increase.<br />
This is on an install size of 1.7GB in total, so this 5MB increase is a 0.3% size increase on the final installed system.<br />
<br />
Note that both of those VMs did not have rpm-plugins-ima installed, which means the file signatures are not put in place.<br />
<br />
When I install the rpm-plugin-ima, and run "dnf reinstall *", the `/usr` directory increases by 0.002% to 1417104.<br />
<br />
<br />
<br />
=== Tie-in to Secure Boot ===<br />
<br />
While using the IMA subsystem in combination with Secure Boot enables users to extend trust on the system out into the binaries executed, there is no requirement at all to use secure boot.<br />
This means that if you have Secure Boot enabled, that enables you to extend the trust, but if you don't want to use secure boot, that has no impact on the IMA subsystem.<br />
<br />
<br />
=== Why in the RPM header, instead of a side-package like -debuginfo? ===<br />
<br />
These signatures would need to get deployed as a filesystem extended attribute in order to be used by the IMA subsystem.<br />
While it is possible to generate the signatures as separate files in a side package, that means that RPM would then need to add code to install extended attributes based on contents of another RPM package.<br />
This would mean that the contents of an e.g. `-file-signature` subpackage won't be deployed to the file systems as normal files, but instead as xattr's on existing files.<br />
<br />
That, together with the minimal size increases of the actual RPMs, made us decide to go with the signature header approach and not implement the side-package method.<br />
<br />
<br />
=== Comparison with MAC's ===<br />
<br />
The IMA subsystem is orthogonal to the Mandatory Access Control systems like selinux, though it is integrated with them.<br />
<br />
Where with selinux you can limit who can read from or write to to which file, IMA will allow you to set policies that enforce file contents to be as expected (signature validated) before they can be read/executed.<br />
<br />
The integration is in the form that you can write a policy line that matches on certain selinux contexts, like for example `dont_appraise obj_type=var_log_t`, to ensure that files of `var_log_t` do not need to be verified, and `appraise obj_type=shell_exec_t` to ensure that any shell that is executed (e.g. bash) is signed with a trusted key.<br />
<br />
== Benefit to Fedora ==<br />
<br />
Having all files signed with a verifiable key means that system owners can use the kernel Integrity and Measurement Architecture (IMA) to enforce only verified files can be executed, or define other policies.<br />
<br />
Having all files signed with Fedora keys would enable integration with for example [https://keylime.dev/|Keylime], which is a CNCF project that implements remote system attestation, based on which a system may or may not get access to secrets and other consequences.<br />
<br />
This feature is wanted by the IoT Edition, for enabling both attestation and local policy verification.<br />
<br />
== Scope ==<br />
* Proposal owners:<br />
The proposal owners will write the code for sigul to pass the required arguments, generate the keys in Infrastructure and get them deployed to the sign vaults.<br />
<br />
* Other developers:<br />
Nothing needed from other developers<br />
<br />
* Release engineering: <br />
A mass rebuild would be nice (as it ensures all packages are signed), but is not required to implement the change itself.<br />
<br />
* Policies and guidelines:<br />
No impact<br />
<br />
* Trademark approval: <br />
No impact<br />
<br />
* Alignment with Objectives: <br />
This aligns with the Internet of Things objective.<br />
<br />
== Upgrade/compatibility impact ==<br />
For standard Fedora users there will be no impact. If an advanced user was already signing their own files (for the Fedora shipped RPMs) for IMA functionality, they will just overwrite the existing signature.<br />
<br />
== How To Test ==<br />
The signatures can be tested “in vitro” by running `evmctl ima_verify --sigfile --key publiccert.der -v myfile.txt`.<br />
This should result in the system reporting “<filename>: verification is OK”.<br />
The full system could be tested by enrolling the Fedora IMA key to the kernel `_ima` keyring, and adding a policy that verifies (some) files to be verified against the key. (instructions to follow).<br />
<br />
== User Experience ==<br />
If the user deploys an IMA policy to verify all or some files, they should be able to trust the signatures made by the Fedora build system.<br />
<br />
== Dependencies ==<br />
No external package dependencies.<br />
<br />
== Contingency Plan ==<br />
<br />
* Contingency mechanism: If the change is not finished in time, we have probably not yet started signing new files. Signing can easily be disabled by updating the config file should issues arise.<br />
If we did start signing, but haven’t signed everything, that is okay, since then packages will get signed as they’re bumped by developers, and they’ll be all signed in the next major release.<br />
<br />
* Contingency deadline: We could ship with this feature in an unfinished state.<br />
* Blocks release? No<br />
* Blocks product? N/A<br />
<br />
== Documentation ==<br />
We intend to write documentation on how to use the IMA subsystem for docs.fedoraproject.org, but that is parallel to this feature itself.<br />
<br />
== Release Notes ==</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Changes/Signed_RPM_Contents&diff=601317Changes/Signed RPM Contents2021-01-20T23:03:33Z<p>Puiterwijk: /* Feedback */</p>
<hr />
<div>= Signed RPM Contents =<br />
<br />
== Summary ==<br />
We want to add signatures to individual files that are part of shipped RPMs.<br />
These signatures will use the Linux IMA (Integrity Measurement Architecture) scheme, which means they can be used to enforce runtime policies to ensure execution of only trusted files.<br />
<br />
== Owner ==<br />
* Name: [[User:Puiterwijk| Patrick Uiterwijk]]<br />
* Email: puiterwijk@redhat.com<br />
* Name: [[User:Pbrobinson| Peter Robinson]]<br />
* Email: pbrobinson@gmail.com<br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<br />
== Current status ==<br />
[[Category:ChangeReadyforFesco]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
[[Category:SystemWideChange]]<br />
<br />
* Targeted release: [[Releases/34 | Fedora 34 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
ASSIGNED -> accepted by FESCo with ongoing development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* FESCo issue: [https://pagure.io/fesco/issue/2547 #2547]<br />
* Tracker bug: <will be assigned by the Wrangler><br />
* Release notes tracker: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
During signing builds, the files in it will be signed with IMA signatures.<br />
These signatures will be made with a key that’s kept by the Fedora Infrastructure team, and installed on the sign vaults.<br />
<br />
These signature can then be used with the Linux Integrity Measurement Architecture (IMA) kernel subsystem to verify files on execution based on a policy.<br />
<br />
The IMA subsystem is described on [https://sourceforge.net/p/linux-ima/wiki/Home/ the project page].<br />
<br />
IMA allows users to extend the trust of their system to the OS and processes.<br />
This means that they can configure a policy based on which the kernel will determine whether to verify (or measure) files before opening them.<br />
You could for example make a policy that appraises (verifies) all files that are executed by root: `appraise uid=1000 appraise_type=imasig`.<br />
<br />
Note explicitly that we do not intend to install a default policy as part of this change, and users will need to deploy their own policy before anything is measured or appraised.<br />
This means that after this is done, users will have the option to enable a policy and have that be enforced, but there will be nothing automatic.<br />
We will, however, document various example policies people can adapt to their needs.<br />
<br />
== Feedback ==<br />
<br />
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. --><br />
<br />
<br />
=== RPM Size ===<br />
One of the main concerns that have been voiced is the RPM size, both on disk (mirrors) and on an installed system.<br />
For this comparison, I have cached all the RPMs installed in a Fedora Rawhide 20210118.n.1 default Server install (server netinstall disk, and then no changed to the group selection).<br />
After creating two copies of that data, one with just resigned (to exclude rpm size difference resulting from different key lengths), and one resigned with IMA file signatures inserted, I then installed two blank VMs by using the standard virt-manager settings, changing only the name and the system type to "EFI".<br />
<br />
This is using a prime256v1 file signing key. This is the same key format supported by the Fedora signing system.<br />
<br />
==== Binary RPMs on disk ====<br />
Resigned: 462524 (452M)<br />
<br />
Resigned+IMA: 467812 (457M)<br />
<br />
This comes down to a 1.1% increase on size of the binary RPMs.<br />
<br />
<br />
==== Installed size ====<br />
On installation of two different VMs, one with the resigned RPMs, and one with the resigned+ima RPMs, the `/usr` directory size does not change at all (both are exactly 1417064 bytes).<br />
<br />
The size of the rpmdb increases from 22952 to 28416 bytes, a 20% increase.<br />
This is on an install size of 1.7GB in total, so this 5MB increase is a 0.3% size increase on the final installed system.<br />
<br />
Note that both of those VMs did not have rpm-plugins-ima installed, which means the file signatures are not put in place.<br />
<br />
When I install the rpm-plugin-ima, and run "dnf reinstall *", the `/usr` directory increases by 0.002% to 1417104.<br />
<br />
<br />
<br />
=== Tie-in to Secure Boot ===<br />
<br />
While using the IMA subsystem in combination with Secure Boot enables users to extend trust on the system out into the binaries executed, there is no requirement at all to use secure boot.<br />
This means that if you have Secure Boot enabled, that enables you to extend the trust, but if you don't want to use secure boot, that has no impact on the IMA subsystem.<br />
<br />
<br />
=== Why in the RPM header, instead of a side-package like -debuginfo? ===<br />
<br />
These signatures would need to get deployed as a filesystem extended attribute in order to be used by the IMA subsystem.<br />
While it is possible to generate the signatures as separate files in a side package, that means that RPM would then need to add code to install extended attributes based on contents of another RPM package.<br />
This would mean that the contents of an e.g. `-file-signature` subpackage won't be deployed to the file systems as normal files, but instead as xattr's on existing files.<br />
<br />
That, together with the minimal size increases of the actual RPMs, made us decide to go with the signature header approach and not implement the side-package method.<br />
<br />
<br />
=== Comparison with MAC's ===<br />
<br />
The IMA subsystem is orthogonal to the Mandatory Access Control systems like selinux, though it is integrated with them.<br />
<br />
Where with selinux you can limit who can read from or write to to which file, IMA will allow you to set policies that enforce file contents to be as expected (signature validated) before they can be read/executed.<br />
<br />
The integration is in the form that you can write a policy line that matches on certain selinux contexts, like for example `dont_appraise obj_type=var_log_t`, to ensure that files of `var_log_t` do not need to be verified, and `appraise obj_type=shell_exec_t` to ensure that any shell that is executed (e.g. bash) is signed with a trusted key.<br />
<br />
== Benefit to Fedora ==<br />
<br />
Having all files signed with a verifiable key means that system owners can use the kernel Integrity and Measurement Architecture (IMA) to enforce only verified files can be executed, or define other policies.<br />
<br />
Having all files signed with Fedora keys would enable integration with for example [https://keylime.dev/|Keylime], which is a CNCF project that implements remote system attestation, based on which a system may or may not get access to secrets and other consequences.<br />
<br />
This feature is wanted by the IoT Edition, for enabling both attestation and local policy verification.<br />
<br />
== Scope ==<br />
* Proposal owners:<br />
The proposal owners will write the code for sigul to pass the required arguments, generate the keys in Infrastructure and get them deployed to the sign vaults.<br />
<br />
* Other developers:<br />
Nothing needed from other developers<br />
<br />
* Release engineering: <br />
A mass rebuild would be nice (as it ensures all packages are signed), but is not required to implement the change itself.<br />
<br />
* Policies and guidelines:<br />
No impact<br />
<br />
* Trademark approval: <br />
No impact<br />
<br />
* Alignment with Objectives: <br />
This aligns with the Internet of Things objective.<br />
<br />
== Upgrade/compatibility impact ==<br />
For standard Fedora users there will be no impact. If an advanced user was already signing their own files (for the Fedora shipped RPMs) for IMA functionality, they will just overwrite the existing signature.<br />
<br />
== How To Test ==<br />
The signatures can be tested “in vitro” by running `evmctl ima_verify --sigfile --key publiccert.der -v myfile.txt`.<br />
This should result in the system reporting “<filename>: verification is OK”.<br />
The full system could be tested by enrolling the Fedora IMA key to the kernel `_ima` keyring, and adding a policy that verifies (some) files to be verified against the key. (instructions to follow).<br />
<br />
== User Experience ==<br />
If the user deploys an IMA policy to verify all or some files, they should be able to trust the signatures made by the Fedora build system.<br />
<br />
== Dependencies ==<br />
No external package dependencies.<br />
<br />
== Contingency Plan ==<br />
<br />
* Contingency mechanism: If the change is not finished in time, we have probably not yet started signing new files. Signing can easily be disabled by updating the config file should issues arise.<br />
If we did start signing, but haven’t signed everything, that is okay, since then packages will get signed as they’re bumped by developers, and they’ll be all signed in the next major release.<br />
<br />
* Contingency deadline: We could ship with this feature in an unfinished state.<br />
* Blocks release? No<br />
* Blocks product? N/A<br />
<br />
== Documentation ==<br />
We intend to write documentation on how to use the IMA subsystem for docs.fedoraproject.org, but that is parallel to this feature itself.<br />
<br />
== Release Notes ==</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Changes/Signed_RPM_Contents&diff=601316Changes/Signed RPM Contents2021-01-20T22:54:09Z<p>Puiterwijk: /* Documentation */</p>
<hr />
<div>= Signed RPM Contents =<br />
<br />
== Summary ==<br />
We want to add signatures to individual files that are part of shipped RPMs.<br />
These signatures will use the Linux IMA (Integrity Measurement Architecture) scheme, which means they can be used to enforce runtime policies to ensure execution of only trusted files.<br />
<br />
== Owner ==<br />
* Name: [[User:Puiterwijk| Patrick Uiterwijk]]<br />
* Email: puiterwijk@redhat.com<br />
* Name: [[User:Pbrobinson| Peter Robinson]]<br />
* Email: pbrobinson@gmail.com<br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<br />
== Current status ==<br />
[[Category:ChangeReadyforFesco]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
[[Category:SystemWideChange]]<br />
<br />
* Targeted release: [[Releases/34 | Fedora 34 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
ASSIGNED -> accepted by FESCo with ongoing development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* FESCo issue: [https://pagure.io/fesco/issue/2547 #2547]<br />
* Tracker bug: <will be assigned by the Wrangler><br />
* Release notes tracker: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
During signing builds, the files in it will be signed with IMA signatures.<br />
These signatures will be made with a key that’s kept by the Fedora Infrastructure team, and installed on the sign vaults.<br />
<br />
These signature can then be used with the Linux Integrity Measurement Architecture (IMA) kernel subsystem to verify files on execution based on a policy.<br />
<br />
The IMA subsystem is described on [https://sourceforge.net/p/linux-ima/wiki/Home/ the project page].<br />
<br />
IMA allows users to extend the trust of their system to the OS and processes.<br />
This means that they can configure a policy based on which the kernel will determine whether to verify (or measure) files before opening them.<br />
You could for example make a policy that appraises (verifies) all files that are executed by root: `appraise uid=1000 appraise_type=imasig`.<br />
<br />
Note explicitly that we do not intend to install a default policy as part of this change, and users will need to deploy their own policy before anything is measured or appraised.<br />
This means that after this is done, users will have the option to enable a policy and have that be enforced, but there will be nothing automatic.<br />
We will, however, document various example policies people can adapt to their needs.<br />
<br />
== Feedback ==<br />
<br />
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. --><br />
<br />
<br />
=== RPM Size ===<br />
One of the main concerns that have been voiced is the RPM size, both on disk (mirrors) and on an installed system.<br />
For this comparison, I have cached all the RPMs installed in a Fedora Rawhide 20210118.n.1 default Server install (server netinstall disk, and then no changed to the group selection).<br />
After creating two copies of that data, one with just resigned (to exclude rpm size difference resulting from different key lengths), and one resigned with IMA file signatures inserted, I then installed two blank VMs by using the standard virt-manager settings, changing only the name and the system type to "EFI".<br />
<br />
This is using a prime256v1 file signing key. This is the same key format supported by the Fedora signing system.<br />
<br />
==== Binary RPMs on disk ====<br />
Resigned: 462524 (452M)<br />
<br />
Resigned+IMA: 467812 (457M)<br />
<br />
This comes down to a 1.1% increase on size of the binary RPMs.<br />
<br />
<br />
==== Installed size ====<br />
On installation of two different VMs, one with the resigned RPMs, and one with the resigned+ima RPMs, the `/usr` directory size does not change at all (both are exactly 1417064 bytes).<br />
<br />
The size of the rpmdb increases from 22952 to 28416 bytes, a 20% increase.<br />
This is on an install size of 1.7GB in total, so this 5MB increase is a 0.3% size increase on the final installed system.<br />
<br />
Note that both of those VMs did not have rpm-plugins-ima installed, which means the file signatures are not put in place.<br />
<br />
When I install the rpm-plugin-ima, and run "dnf reinstall *", the `/usr` directory increases by 0.002% to 1417104.<br />
<br />
<br />
<br />
=== Tie-in to Secure Boot ===<br />
<br />
While using the IMA subsystem in combination with Secure Boot enables users to extend trust on the system out into the binaries executed, there is no requirement at all to use secure boot.<br />
This means that if you have Secure Boot enabled, that enables you to extend the trust, but if you don't want to use secure boot, that has no impact on the IMA subsystem.<br />
<br />
<br />
=== Why in the RPM header, instead of a side-package like -debuginfo? ===<br />
<br />
These signatures would need to get deployed as a filesystem extended attribute in order to be used by the IMA subsystem.<br />
While it is possible to generate the signatures as separate files in a side package, that means that RPM would then need to add code to install extended attributes based on contents of another RPM package.<br />
This would mean that the contents of an e.g. `-file-signature` subpackage won't be deployed to the file systems as normal files, but instead as xattr's on existing files.<br />
<br />
That, together with the minimal size increases of the actual RPMs, made us decide to go with the signature header approach and not implement the side-package method.<br />
<br />
== Benefit to Fedora ==<br />
<br />
Having all files signed with a verifiable key means that system owners can use the kernel Integrity and Measurement Architecture (IMA) to enforce only verified files can be executed, or define other policies.<br />
<br />
Having all files signed with Fedora keys would enable integration with for example [https://keylime.dev/|Keylime], which is a CNCF project that implements remote system attestation, based on which a system may or may not get access to secrets and other consequences.<br />
<br />
This feature is wanted by the IoT Edition, for enabling both attestation and local policy verification.<br />
<br />
== Scope ==<br />
* Proposal owners:<br />
The proposal owners will write the code for sigul to pass the required arguments, generate the keys in Infrastructure and get them deployed to the sign vaults.<br />
<br />
* Other developers:<br />
Nothing needed from other developers<br />
<br />
* Release engineering: <br />
A mass rebuild would be nice (as it ensures all packages are signed), but is not required to implement the change itself.<br />
<br />
* Policies and guidelines:<br />
No impact<br />
<br />
* Trademark approval: <br />
No impact<br />
<br />
* Alignment with Objectives: <br />
This aligns with the Internet of Things objective.<br />
<br />
== Upgrade/compatibility impact ==<br />
For standard Fedora users there will be no impact. If an advanced user was already signing their own files (for the Fedora shipped RPMs) for IMA functionality, they will just overwrite the existing signature.<br />
<br />
== How To Test ==<br />
The signatures can be tested “in vitro” by running `evmctl ima_verify --sigfile --key publiccert.der -v myfile.txt`.<br />
This should result in the system reporting “<filename>: verification is OK”.<br />
The full system could be tested by enrolling the Fedora IMA key to the kernel `_ima` keyring, and adding a policy that verifies (some) files to be verified against the key. (instructions to follow).<br />
<br />
== User Experience ==<br />
If the user deploys an IMA policy to verify all or some files, they should be able to trust the signatures made by the Fedora build system.<br />
<br />
== Dependencies ==<br />
No external package dependencies.<br />
<br />
== Contingency Plan ==<br />
<br />
* Contingency mechanism: If the change is not finished in time, we have probably not yet started signing new files. Signing can easily be disabled by updating the config file should issues arise.<br />
If we did start signing, but haven’t signed everything, that is okay, since then packages will get signed as they’re bumped by developers, and they’ll be all signed in the next major release.<br />
<br />
* Contingency deadline: We could ship with this feature in an unfinished state.<br />
* Blocks release? No<br />
* Blocks product? N/A<br />
<br />
== Documentation ==<br />
We intend to write documentation on how to use the IMA subsystem for docs.fedoraproject.org, but that is parallel to this feature itself.<br />
<br />
== Release Notes ==</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Changes/Signed_RPM_Contents&diff=601315Changes/Signed RPM Contents2021-01-20T22:51:37Z<p>Puiterwijk: /* Feedback */</p>
<hr />
<div>= Signed RPM Contents =<br />
<br />
== Summary ==<br />
We want to add signatures to individual files that are part of shipped RPMs.<br />
These signatures will use the Linux IMA (Integrity Measurement Architecture) scheme, which means they can be used to enforce runtime policies to ensure execution of only trusted files.<br />
<br />
== Owner ==<br />
* Name: [[User:Puiterwijk| Patrick Uiterwijk]]<br />
* Email: puiterwijk@redhat.com<br />
* Name: [[User:Pbrobinson| Peter Robinson]]<br />
* Email: pbrobinson@gmail.com<br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<br />
== Current status ==<br />
[[Category:ChangeReadyforFesco]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
[[Category:SystemWideChange]]<br />
<br />
* Targeted release: [[Releases/34 | Fedora 34 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
ASSIGNED -> accepted by FESCo with ongoing development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* FESCo issue: [https://pagure.io/fesco/issue/2547 #2547]<br />
* Tracker bug: <will be assigned by the Wrangler><br />
* Release notes tracker: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
During signing builds, the files in it will be signed with IMA signatures.<br />
These signatures will be made with a key that’s kept by the Fedora Infrastructure team, and installed on the sign vaults.<br />
<br />
These signature can then be used with the Linux Integrity Measurement Architecture (IMA) kernel subsystem to verify files on execution based on a policy.<br />
<br />
The IMA subsystem is described on [https://sourceforge.net/p/linux-ima/wiki/Home/ the project page].<br />
<br />
IMA allows users to extend the trust of their system to the OS and processes.<br />
This means that they can configure a policy based on which the kernel will determine whether to verify (or measure) files before opening them.<br />
You could for example make a policy that appraises (verifies) all files that are executed by root: `appraise uid=1000 appraise_type=imasig`.<br />
<br />
Note explicitly that we do not intend to install a default policy as part of this change, and users will need to deploy their own policy before anything is measured or appraised.<br />
This means that after this is done, users will have the option to enable a policy and have that be enforced, but there will be nothing automatic.<br />
We will, however, document various example policies people can adapt to their needs.<br />
<br />
== Feedback ==<br />
<br />
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. --><br />
<br />
<br />
=== RPM Size ===<br />
One of the main concerns that have been voiced is the RPM size, both on disk (mirrors) and on an installed system.<br />
For this comparison, I have cached all the RPMs installed in a Fedora Rawhide 20210118.n.1 default Server install (server netinstall disk, and then no changed to the group selection).<br />
After creating two copies of that data, one with just resigned (to exclude rpm size difference resulting from different key lengths), and one resigned with IMA file signatures inserted, I then installed two blank VMs by using the standard virt-manager settings, changing only the name and the system type to "EFI".<br />
<br />
This is using a prime256v1 file signing key. This is the same key format supported by the Fedora signing system.<br />
<br />
==== Binary RPMs on disk ====<br />
Resigned: 462524 (452M)<br />
<br />
Resigned+IMA: 467812 (457M)<br />
<br />
This comes down to a 1.1% increase on size of the binary RPMs.<br />
<br />
<br />
==== Installed size ====<br />
On installation of two different VMs, one with the resigned RPMs, and one with the resigned+ima RPMs, the `/usr` directory size does not change at all (both are exactly 1417064 bytes).<br />
<br />
The size of the rpmdb increases from 22952 to 28416 bytes, a 20% increase.<br />
This is on an install size of 1.7GB in total, so this 5MB increase is a 0.3% size increase on the final installed system.<br />
<br />
Note that both of those VMs did not have rpm-plugins-ima installed, which means the file signatures are not put in place.<br />
<br />
When I install the rpm-plugin-ima, and run "dnf reinstall *", the `/usr` directory increases by 0.002% to 1417104.<br />
<br />
<br />
<br />
=== Tie-in to Secure Boot ===<br />
<br />
While using the IMA subsystem in combination with Secure Boot enables users to extend trust on the system out into the binaries executed, there is no requirement at all to use secure boot.<br />
This means that if you have Secure Boot enabled, that enables you to extend the trust, but if you don't want to use secure boot, that has no impact on the IMA subsystem.<br />
<br />
<br />
=== Why in the RPM header, instead of a side-package like -debuginfo? ===<br />
<br />
These signatures would need to get deployed as a filesystem extended attribute in order to be used by the IMA subsystem.<br />
While it is possible to generate the signatures as separate files in a side package, that means that RPM would then need to add code to install extended attributes based on contents of another RPM package.<br />
This would mean that the contents of an e.g. `-file-signature` subpackage won't be deployed to the file systems as normal files, but instead as xattr's on existing files.<br />
<br />
That, together with the minimal size increases of the actual RPMs, made us decide to go with the signature header approach and not implement the side-package method.<br />
<br />
== Benefit to Fedora ==<br />
<br />
Having all files signed with a verifiable key means that system owners can use the kernel Integrity and Measurement Architecture (IMA) to enforce only verified files can be executed, or define other policies.<br />
<br />
Having all files signed with Fedora keys would enable integration with for example [https://keylime.dev/|Keylime], which is a CNCF project that implements remote system attestation, based on which a system may or may not get access to secrets and other consequences.<br />
<br />
This feature is wanted by the IoT Edition, for enabling both attestation and local policy verification.<br />
<br />
== Scope ==<br />
* Proposal owners:<br />
The proposal owners will write the code for sigul to pass the required arguments, generate the keys in Infrastructure and get them deployed to the sign vaults.<br />
<br />
* Other developers:<br />
Nothing needed from other developers<br />
<br />
* Release engineering: <br />
A mass rebuild would be nice (as it ensures all packages are signed), but is not required to implement the change itself.<br />
<br />
* Policies and guidelines:<br />
No impact<br />
<br />
* Trademark approval: <br />
No impact<br />
<br />
* Alignment with Objectives: <br />
This aligns with the Internet of Things objective.<br />
<br />
== Upgrade/compatibility impact ==<br />
For standard Fedora users there will be no impact. If an advanced user was already signing their own files (for the Fedora shipped RPMs) for IMA functionality, they will just overwrite the existing signature.<br />
<br />
== How To Test ==<br />
The signatures can be tested “in vitro” by running `evmctl ima_verify --sigfile --key publiccert.der -v myfile.txt`.<br />
This should result in the system reporting “<filename>: verification is OK”.<br />
The full system could be tested by enrolling the Fedora IMA key to the kernel `_ima` keyring, and adding a policy that verifies (some) files to be verified against the key. (instructions to follow).<br />
<br />
== User Experience ==<br />
If the user deploys an IMA policy to verify all or some files, they should be able to trust the signatures made by the Fedora build system.<br />
<br />
== Dependencies ==<br />
No external package dependencies.<br />
<br />
== Contingency Plan ==<br />
<br />
* Contingency mechanism: If the change is not finished in time, we have probably not yet started signing new files. Signing can easily be disabled by updating the config file should issues arise.<br />
If we did start signing, but haven’t signed everything, that is okay, since then packages will get signed as they’re bumped by developers, and they’ll be all signed in the next major release.<br />
<br />
* Contingency deadline: We could ship with this feature in an unfinished state.<br />
* Blocks release? No<br />
* Blocks product? N/A<br />
<br />
== Documentation ==<br />
Documentation to follow.<br />
<br />
== Release Notes ==</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Changes/Signed_RPM_Contents&diff=601314Changes/Signed RPM Contents2021-01-20T22:47:45Z<p>Puiterwijk: /* Benefit to Fedora */</p>
<hr />
<div>= Signed RPM Contents =<br />
<br />
== Summary ==<br />
We want to add signatures to individual files that are part of shipped RPMs.<br />
These signatures will use the Linux IMA (Integrity Measurement Architecture) scheme, which means they can be used to enforce runtime policies to ensure execution of only trusted files.<br />
<br />
== Owner ==<br />
* Name: [[User:Puiterwijk| Patrick Uiterwijk]]<br />
* Email: puiterwijk@redhat.com<br />
* Name: [[User:Pbrobinson| Peter Robinson]]<br />
* Email: pbrobinson@gmail.com<br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<br />
== Current status ==<br />
[[Category:ChangeReadyforFesco]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
[[Category:SystemWideChange]]<br />
<br />
* Targeted release: [[Releases/34 | Fedora 34 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
ASSIGNED -> accepted by FESCo with ongoing development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* FESCo issue: [https://pagure.io/fesco/issue/2547 #2547]<br />
* Tracker bug: <will be assigned by the Wrangler><br />
* Release notes tracker: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
During signing builds, the files in it will be signed with IMA signatures.<br />
These signatures will be made with a key that’s kept by the Fedora Infrastructure team, and installed on the sign vaults.<br />
<br />
These signature can then be used with the Linux Integrity Measurement Architecture (IMA) kernel subsystem to verify files on execution based on a policy.<br />
<br />
The IMA subsystem is described on [https://sourceforge.net/p/linux-ima/wiki/Home/ the project page].<br />
<br />
IMA allows users to extend the trust of their system to the OS and processes.<br />
This means that they can configure a policy based on which the kernel will determine whether to verify (or measure) files before opening them.<br />
You could for example make a policy that appraises (verifies) all files that are executed by root: `appraise uid=1000 appraise_type=imasig`.<br />
<br />
Note explicitly that we do not intend to install a default policy as part of this change, and users will need to deploy their own policy before anything is measured or appraised.<br />
This means that after this is done, users will have the option to enable a policy and have that be enforced, but there will be nothing automatic.<br />
We will, however, document various example policies people can adapt to their needs.<br />
<br />
== Feedback ==<br />
<br />
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. --><br />
<br />
<br />
=== RPM Size ===<br />
One of the main concerns that have been voiced is the RPM size, both on disk (mirrors) and on an installed system.<br />
For this comparison, I have cached all the RPMs installed in a Fedora Rawhide 20210118.n.1 default Server install (server netinstall disk, and then no changed to the group selection).<br />
After creating two copies of that data, one with just resigned (to exclude rpm size difference resulting from different key lengths), and one resigned with IMA file signatures inserted, I then installed two blank VMs by using the standard virt-manager settings, changing only the name and the system type to "EFI".<br />
<br />
This is using a prime256v1 file signing key. This is the same key format supported by the Fedora signing system.<br />
<br />
==== Binary RPMs on disk ====<br />
Resigned: 462524 (452M)<br />
<br />
Resigned+IMA: 467812 (457M)<br />
<br />
This comes down to a 1.1% increase on size of the binary RPMs.<br />
<br />
<br />
==== Installed size ====<br />
On installation of two different VMs, one with the resigned RPMs, and one with the resigned+ima RPMs, the `/usr` directory size does not change at all (both are exactly 1417064 bytes).<br />
<br />
The size of the rpmdb increases from 22952 to 28416 bytes, a 20% increase.<br />
This is on an install size of 1.7GB in total, so this 5MB increase is a 0.3% size increase on the final installed system.<br />
<br />
Note that both of those VMs did not have rpm-plugins-ima installed, which means the file signatures are not put in place.<br />
<br />
When I install the rpm-plugin-ima, and run "dnf reinstall *", the `/usr` directory increases by 0.002% to 1417104.<br />
<br />
<br />
<br />
=== Tie-in to Secure Boot ===<br />
<br />
While using the IMA subsystem in combination with Secure Boot enables users to extend trust on the system out into the binaries executed, there is no requirement at all to use secure boot.<br />
This means that if you have Secure Boot enabled, that enables you to extend the trust, but if you don't want to use secure boot, that has no impact on the IMA subsystem.<br />
<br />
== Benefit to Fedora ==<br />
<br />
Having all files signed with a verifiable key means that system owners can use the kernel Integrity and Measurement Architecture (IMA) to enforce only verified files can be executed, or define other policies.<br />
<br />
Having all files signed with Fedora keys would enable integration with for example [https://keylime.dev/|Keylime], which is a CNCF project that implements remote system attestation, based on which a system may or may not get access to secrets and other consequences.<br />
<br />
This feature is wanted by the IoT Edition, for enabling both attestation and local policy verification.<br />
<br />
== Scope ==<br />
* Proposal owners:<br />
The proposal owners will write the code for sigul to pass the required arguments, generate the keys in Infrastructure and get them deployed to the sign vaults.<br />
<br />
* Other developers:<br />
Nothing needed from other developers<br />
<br />
* Release engineering: <br />
A mass rebuild would be nice (as it ensures all packages are signed), but is not required to implement the change itself.<br />
<br />
* Policies and guidelines:<br />
No impact<br />
<br />
* Trademark approval: <br />
No impact<br />
<br />
* Alignment with Objectives: <br />
This aligns with the Internet of Things objective.<br />
<br />
== Upgrade/compatibility impact ==<br />
For standard Fedora users there will be no impact. If an advanced user was already signing their own files (for the Fedora shipped RPMs) for IMA functionality, they will just overwrite the existing signature.<br />
<br />
== How To Test ==<br />
The signatures can be tested “in vitro” by running `evmctl ima_verify --sigfile --key publiccert.der -v myfile.txt`.<br />
This should result in the system reporting “<filename>: verification is OK”.<br />
The full system could be tested by enrolling the Fedora IMA key to the kernel `_ima` keyring, and adding a policy that verifies (some) files to be verified against the key. (instructions to follow).<br />
<br />
== User Experience ==<br />
If the user deploys an IMA policy to verify all or some files, they should be able to trust the signatures made by the Fedora build system.<br />
<br />
== Dependencies ==<br />
No external package dependencies.<br />
<br />
== Contingency Plan ==<br />
<br />
* Contingency mechanism: If the change is not finished in time, we have probably not yet started signing new files. Signing can easily be disabled by updating the config file should issues arise.<br />
If we did start signing, but haven’t signed everything, that is okay, since then packages will get signed as they’re bumped by developers, and they’ll be all signed in the next major release.<br />
<br />
* Contingency deadline: We could ship with this feature in an unfinished state.<br />
* Blocks release? No<br />
* Blocks product? N/A<br />
<br />
== Documentation ==<br />
Documentation to follow.<br />
<br />
== Release Notes ==</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Changes/Signed_RPM_Contents&diff=601313Changes/Signed RPM Contents2021-01-20T22:42:52Z<p>Puiterwijk: /* Feedback */</p>
<hr />
<div>= Signed RPM Contents =<br />
<br />
== Summary ==<br />
We want to add signatures to individual files that are part of shipped RPMs.<br />
These signatures will use the Linux IMA (Integrity Measurement Architecture) scheme, which means they can be used to enforce runtime policies to ensure execution of only trusted files.<br />
<br />
== Owner ==<br />
* Name: [[User:Puiterwijk| Patrick Uiterwijk]]<br />
* Email: puiterwijk@redhat.com<br />
* Name: [[User:Pbrobinson| Peter Robinson]]<br />
* Email: pbrobinson@gmail.com<br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<br />
== Current status ==<br />
[[Category:ChangeReadyforFesco]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
[[Category:SystemWideChange]]<br />
<br />
* Targeted release: [[Releases/34 | Fedora 34 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
ASSIGNED -> accepted by FESCo with ongoing development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* FESCo issue: [https://pagure.io/fesco/issue/2547 #2547]<br />
* Tracker bug: <will be assigned by the Wrangler><br />
* Release notes tracker: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
During signing builds, the files in it will be signed with IMA signatures.<br />
These signatures will be made with a key that’s kept by the Fedora Infrastructure team, and installed on the sign vaults.<br />
<br />
These signature can then be used with the Linux Integrity Measurement Architecture (IMA) kernel subsystem to verify files on execution based on a policy.<br />
<br />
The IMA subsystem is described on [https://sourceforge.net/p/linux-ima/wiki/Home/ the project page].<br />
<br />
IMA allows users to extend the trust of their system to the OS and processes.<br />
This means that they can configure a policy based on which the kernel will determine whether to verify (or measure) files before opening them.<br />
You could for example make a policy that appraises (verifies) all files that are executed by root: `appraise uid=1000 appraise_type=imasig`.<br />
<br />
Note explicitly that we do not intend to install a default policy as part of this change, and users will need to deploy their own policy before anything is measured or appraised.<br />
This means that after this is done, users will have the option to enable a policy and have that be enforced, but there will be nothing automatic.<br />
We will, however, document various example policies people can adapt to their needs.<br />
<br />
== Feedback ==<br />
<br />
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. --><br />
<br />
<br />
=== RPM Size ===<br />
One of the main concerns that have been voiced is the RPM size, both on disk (mirrors) and on an installed system.<br />
For this comparison, I have cached all the RPMs installed in a Fedora Rawhide 20210118.n.1 default Server install (server netinstall disk, and then no changed to the group selection).<br />
After creating two copies of that data, one with just resigned (to exclude rpm size difference resulting from different key lengths), and one resigned with IMA file signatures inserted, I then installed two blank VMs by using the standard virt-manager settings, changing only the name and the system type to "EFI".<br />
<br />
This is using a prime256v1 file signing key. This is the same key format supported by the Fedora signing system.<br />
<br />
==== Binary RPMs on disk ====<br />
Resigned: 462524 (452M)<br />
<br />
Resigned+IMA: 467812 (457M)<br />
<br />
This comes down to a 1.1% increase on size of the binary RPMs.<br />
<br />
<br />
==== Installed size ====<br />
On installation of two different VMs, one with the resigned RPMs, and one with the resigned+ima RPMs, the `/usr` directory size does not change at all (both are exactly 1417064 bytes).<br />
<br />
The size of the rpmdb increases from 22952 to 28416 bytes, a 20% increase.<br />
This is on an install size of 1.7GB in total, so this 5MB increase is a 0.3% size increase on the final installed system.<br />
<br />
Note that both of those VMs did not have rpm-plugins-ima installed, which means the file signatures are not put in place.<br />
<br />
When I install the rpm-plugin-ima, and run "dnf reinstall *", the `/usr` directory increases by 0.002% to 1417104.<br />
<br />
<br />
<br />
=== Tie-in to Secure Boot ===<br />
<br />
While using the IMA subsystem in combination with Secure Boot enables users to extend trust on the system out into the binaries executed, there is no requirement at all to use secure boot.<br />
This means that if you have Secure Boot enabled, that enables you to extend the trust, but if you don't want to use secure boot, that has no impact on the IMA subsystem.<br />
<br />
== Benefit to Fedora ==<br />
<br />
Having all files signed with a verifiable key means that system owners can use the kernel Integrity and Measurement Architecture (IMA) to enforce only verified files can be executed, or define other policies.<br />
<br />
== Scope ==<br />
* Proposal owners:<br />
The proposal owners will write the code for sigul to pass the required arguments, generate the keys in Infrastructure and get them deployed to the sign vaults.<br />
<br />
* Other developers:<br />
Nothing needed from other developers<br />
<br />
* Release engineering: <br />
A mass rebuild would be nice (as it ensures all packages are signed), but is not required to implement the change itself.<br />
<br />
* Policies and guidelines:<br />
No impact<br />
<br />
* Trademark approval: <br />
No impact<br />
<br />
* Alignment with Objectives: <br />
This aligns with the Internet of Things objective.<br />
<br />
== Upgrade/compatibility impact ==<br />
For standard Fedora users there will be no impact. If an advanced user was already signing their own files (for the Fedora shipped RPMs) for IMA functionality, they will just overwrite the existing signature.<br />
<br />
== How To Test ==<br />
The signatures can be tested “in vitro” by running `evmctl ima_verify --sigfile --key publiccert.der -v myfile.txt`.<br />
This should result in the system reporting “<filename>: verification is OK”.<br />
The full system could be tested by enrolling the Fedora IMA key to the kernel `_ima` keyring, and adding a policy that verifies (some) files to be verified against the key. (instructions to follow).<br />
<br />
== User Experience ==<br />
If the user deploys an IMA policy to verify all or some files, they should be able to trust the signatures made by the Fedora build system.<br />
<br />
== Dependencies ==<br />
No external package dependencies.<br />
<br />
== Contingency Plan ==<br />
<br />
* Contingency mechanism: If the change is not finished in time, we have probably not yet started signing new files. Signing can easily be disabled by updating the config file should issues arise.<br />
If we did start signing, but haven’t signed everything, that is okay, since then packages will get signed as they’re bumped by developers, and they’ll be all signed in the next major release.<br />
<br />
* Contingency deadline: We could ship with this feature in an unfinished state.<br />
* Blocks release? No<br />
* Blocks product? N/A<br />
<br />
== Documentation ==<br />
Documentation to follow.<br />
<br />
== Release Notes ==</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Changes/Signed_RPM_Contents&diff=601312Changes/Signed RPM Contents2021-01-20T22:36:49Z<p>Puiterwijk: /* Detailed Description */</p>
<hr />
<div>= Signed RPM Contents =<br />
<br />
== Summary ==<br />
We want to add signatures to individual files that are part of shipped RPMs.<br />
These signatures will use the Linux IMA (Integrity Measurement Architecture) scheme, which means they can be used to enforce runtime policies to ensure execution of only trusted files.<br />
<br />
== Owner ==<br />
* Name: [[User:Puiterwijk| Patrick Uiterwijk]]<br />
* Email: puiterwijk@redhat.com<br />
* Name: [[User:Pbrobinson| Peter Robinson]]<br />
* Email: pbrobinson@gmail.com<br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<br />
== Current status ==<br />
[[Category:ChangeReadyforFesco]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
[[Category:SystemWideChange]]<br />
<br />
* Targeted release: [[Releases/34 | Fedora 34 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
ASSIGNED -> accepted by FESCo with ongoing development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* FESCo issue: [https://pagure.io/fesco/issue/2547 #2547]<br />
* Tracker bug: <will be assigned by the Wrangler><br />
* Release notes tracker: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
During signing builds, the files in it will be signed with IMA signatures.<br />
These signatures will be made with a key that’s kept by the Fedora Infrastructure team, and installed on the sign vaults.<br />
<br />
These signature can then be used with the Linux Integrity Measurement Architecture (IMA) kernel subsystem to verify files on execution based on a policy.<br />
<br />
The IMA subsystem is described on [https://sourceforge.net/p/linux-ima/wiki/Home/ the project page].<br />
<br />
IMA allows users to extend the trust of their system to the OS and processes.<br />
This means that they can configure a policy based on which the kernel will determine whether to verify (or measure) files before opening them.<br />
You could for example make a policy that appraises (verifies) all files that are executed by root: `appraise uid=1000 appraise_type=imasig`.<br />
<br />
Note explicitly that we do not intend to install a default policy as part of this change, and users will need to deploy their own policy before anything is measured or appraised.<br />
This means that after this is done, users will have the option to enable a policy and have that be enforced, but there will be nothing automatic.<br />
We will, however, document various example policies people can adapt to their needs.<br />
<br />
== Feedback ==<br />
<br />
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. --><br />
<br />
<br />
=== RPM Size ===<br />
One of the main concerns that have been voiced is the RPM size, both on disk (mirrors) and on an installed system.<br />
For this comparison, I have cached all the RPMs installed in a Fedora Rawhide 20210118.n.1 default Server install (server netinstall disk, and then no changed to the group selection).<br />
After creating two copies of that data, one with just resigned (to exclude rpm size difference resulting from different key lengths), and one resigned with IMA file signatures inserted, I then installed two blank VMs by using the standard virt-manager settings, changing only the name and the system type to "EFI".<br />
<br />
This is using a prime256v1 file signing key. This is the same key format supported by the Fedora signing system.<br />
<br />
==== Binary RPMs on disk ====<br />
Resigned: 462524 (452M)<br />
<br />
Resigned+IMA: 467812 (457M)<br />
<br />
This comes down to a 1.1% increase on size of the binary RPMs.<br />
<br />
<br />
==== Installed size ====<br />
On installation of two different VMs, one with the resigned RPMs, and one with the resigned+ima RPMs, the `/usr` directory size does not change at all (both are exactly 1417064 bytes).<br />
<br />
The size of the rpmdb increases from 22952 to 28416 bytes, a 20% increase.<br />
This is on an install size of 1.7GB in total, so this 5MB increase is a 0.3% size increase on the final installed system.<br />
<br />
Note that both of those VMs did not have rpm-plugins-ima installed, which means the file signatures are not put in place.<br />
<br />
When I install the rpm-plugin-ima, and run "dnf reinstall *", the `/usr` directory increases by 0.002% to 1417104.<br />
<br />
== Benefit to Fedora ==<br />
<br />
Having all files signed with a verifiable key means that system owners can use the kernel Integrity and Measurement Architecture (IMA) to enforce only verified files can be executed, or define other policies.<br />
<br />
== Scope ==<br />
* Proposal owners:<br />
The proposal owners will write the code for sigul to pass the required arguments, generate the keys in Infrastructure and get them deployed to the sign vaults.<br />
<br />
* Other developers:<br />
Nothing needed from other developers<br />
<br />
* Release engineering: <br />
A mass rebuild would be nice (as it ensures all packages are signed), but is not required to implement the change itself.<br />
<br />
* Policies and guidelines:<br />
No impact<br />
<br />
* Trademark approval: <br />
No impact<br />
<br />
* Alignment with Objectives: <br />
This aligns with the Internet of Things objective.<br />
<br />
== Upgrade/compatibility impact ==<br />
For standard Fedora users there will be no impact. If an advanced user was already signing their own files (for the Fedora shipped RPMs) for IMA functionality, they will just overwrite the existing signature.<br />
<br />
== How To Test ==<br />
The signatures can be tested “in vitro” by running `evmctl ima_verify --sigfile --key publiccert.der -v myfile.txt`.<br />
This should result in the system reporting “<filename>: verification is OK”.<br />
The full system could be tested by enrolling the Fedora IMA key to the kernel `_ima` keyring, and adding a policy that verifies (some) files to be verified against the key. (instructions to follow).<br />
<br />
== User Experience ==<br />
If the user deploys an IMA policy to verify all or some files, they should be able to trust the signatures made by the Fedora build system.<br />
<br />
== Dependencies ==<br />
No external package dependencies.<br />
<br />
== Contingency Plan ==<br />
<br />
* Contingency mechanism: If the change is not finished in time, we have probably not yet started signing new files. Signing can easily be disabled by updating the config file should issues arise.<br />
If we did start signing, but haven’t signed everything, that is okay, since then packages will get signed as they’re bumped by developers, and they’ll be all signed in the next major release.<br />
<br />
* Contingency deadline: We could ship with this feature in an unfinished state.<br />
* Blocks release? No<br />
* Blocks product? N/A<br />
<br />
== Documentation ==<br />
Documentation to follow.<br />
<br />
== Release Notes ==</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Changes/Signed_RPM_Contents&diff=601305Changes/Signed RPM Contents2021-01-20T21:18:21Z<p>Puiterwijk: Add RPM size numbers</p>
<hr />
<div>= Signed RPM Contents =<br />
<br />
== Summary ==<br />
We want to add signatures to individual files that are part of shipped RPMs.<br />
These signatures will use the Linux IMA (Integrity Measurement Architecture) scheme, which means they can be used to enforce runtime policies to ensure execution of only trusted files.<br />
<br />
== Owner ==<br />
* Name: [[User:Puiterwijk| Patrick Uiterwijk]]<br />
* Email: puiterwijk@redhat.com<br />
* Name: [[User:Pbrobinson| Peter Robinson]]<br />
* Email: pbrobinson@gmail.com<br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<br />
== Current status ==<br />
[[Category:ChangeReadyforFesco]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
[[Category:SystemWideChange]]<br />
<br />
* Targeted release: [[Releases/34 | Fedora 34 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
ASSIGNED -> accepted by FESCo with ongoing development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* FESCo issue: [https://pagure.io/fesco/issue/2547 #2547]<br />
* Tracker bug: <will be assigned by the Wrangler><br />
* Release notes tracker: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
During signing builds, the files in it will be signed with IMA signatures..<br />
These signatures will be made with a key that’s kept by the Fedora Infrastructure team, and installed on the sign vaults.<br />
<br />
== Feedback ==<br />
<br />
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. --><br />
<br />
<br />
=== RPM Size ===<br />
One of the main concerns that have been voiced is the RPM size, both on disk (mirrors) and on an installed system.<br />
For this comparison, I have cached all the RPMs installed in a Fedora Rawhide 20210118.n.1 default Server install (server netinstall disk, and then no changed to the group selection).<br />
After creating two copies of that data, one with just resigned (to exclude rpm size difference resulting from different key lengths), and one resigned with IMA file signatures inserted, I then installed two blank VMs by using the standard virt-manager settings, changing only the name and the system type to "EFI".<br />
<br />
This is using a prime256v1 file signing key. This is the same key format supported by the Fedora signing system.<br />
<br />
==== Binary RPMs on disk ====<br />
Resigned: 462524 (452M)<br />
<br />
Resigned+IMA: 467812 (457M)<br />
<br />
This comes down to a 1.1% increase on size of the binary RPMs.<br />
<br />
<br />
==== Installed size ====<br />
On installation of two different VMs, one with the resigned RPMs, and one with the resigned+ima RPMs, the `/usr` directory size does not change at all (both are exactly 1417064 bytes).<br />
<br />
The size of the rpmdb increases from 22952 to 28416 bytes, a 20% increase.<br />
This is on an install size of 1.7GB in total, so this 5MB increase is a 0.3% size increase on the final installed system.<br />
<br />
Note that both of those VMs did not have rpm-plugins-ima installed, which means the file signatures are not put in place.<br />
<br />
When I install the rpm-plugin-ima, and run "dnf reinstall *", the `/usr` directory increases by 0.002% to 1417104.<br />
<br />
== Benefit to Fedora ==<br />
<br />
Having all files signed with a verifiable key means that system owners can use the kernel Integrity and Measurement Architecture (IMA) to enforce only verified files can be executed, or define other policies.<br />
<br />
== Scope ==<br />
* Proposal owners:<br />
The proposal owners will write the code for sigul to pass the required arguments, generate the keys in Infrastructure and get them deployed to the sign vaults.<br />
<br />
* Other developers:<br />
Nothing needed from other developers<br />
<br />
* Release engineering: <br />
A mass rebuild would be nice (as it ensures all packages are signed), but is not required to implement the change itself.<br />
<br />
* Policies and guidelines:<br />
No impact<br />
<br />
* Trademark approval: <br />
No impact<br />
<br />
* Alignment with Objectives: <br />
This aligns with the Internet of Things objective.<br />
<br />
== Upgrade/compatibility impact ==<br />
For standard Fedora users there will be no impact. If an advanced user was already signing their own files (for the Fedora shipped RPMs) for IMA functionality, they will just overwrite the existing signature.<br />
<br />
== How To Test ==<br />
The signatures can be tested “in vitro” by running `evmctl ima_verify --sigfile --key publiccert.der -v myfile.txt`.<br />
This should result in the system reporting “<filename>: verification is OK”.<br />
The full system could be tested by enrolling the Fedora IMA key to the kernel `_ima` keyring, and adding a policy that verifies (some) files to be verified against the key. (instructions to follow).<br />
<br />
== User Experience ==<br />
If the user deploys an IMA policy to verify all or some files, they should be able to trust the signatures made by the Fedora build system.<br />
<br />
== Dependencies ==<br />
No external package dependencies.<br />
<br />
== Contingency Plan ==<br />
<br />
* Contingency mechanism: If the change is not finished in time, we have probably not yet started signing new files. Signing can easily be disabled by updating the config file should issues arise.<br />
If we did start signing, but haven’t signed everything, that is okay, since then packages will get signed as they’re bumped by developers, and they’ll be all signed in the next major release.<br />
<br />
* Contingency deadline: We could ship with this feature in an unfinished state.<br />
* Blocks release? No<br />
* Blocks product? N/A<br />
<br />
== Documentation ==<br />
Documentation to follow.<br />
<br />
== Release Notes ==</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Infrastructure/Authentication&diff=599955Infrastructure/Authentication2021-01-09T15:35:20Z<p>Puiterwijk: Fix typo in description string</p>
<hr />
<div>= OpenID Connect Authentication =<br />
Fedora Infrastructure is using [https://openid.net/connect/ OpenID Connect] authentication, and this page is used to document the implementation details.<br />
<br />
For development purposes, there is https://iddev.fedorainfracloud.org/. For staging and production client secrets please file an Infrastructure ticket.<br />
<br />
== Terminology ==<br />
Some basic terminology required to read this page:<br />
* OpenID Provider (OP): the Ipsilon deployment, this is the part that does user authentication and issues tokens<br />
* Identity Provider (IdP): see OpenID Provider<br />
* Relying Party (RP): any application that runs the OpenID Connect protocol.<br />
* Resource Server: any application that accepts tokens issued by the OpenID Provider.<br />
* UserInfo: HTTP endpoint provided by Ipsilon to provide information about the user that authorized a token.<br />
<br />
== Endpoint URLs ==<br />
* Configuration URL for dynamic configuration: https://id.fedoraproject.org/openidc/.well-known/openid-configuration<br />
* Authorization Endpoint: https://id.fedoraproject.org/openidc/Authorization<br />
* Token Endpoint: https://id.fedoraproject.org/openidc/Token<br />
* UserInfo Endpoint: https://id.fedoraproject.org/openidc/UserInfo<br />
* Token Introspection URL: https://id.fedoraproject.org/openidc/TokenInfo<br />
<br />
== Suggested implementations ==<br />
For Flask, the suggested client is [https://github.com/puiterwijk/flask-oidc Flask-OIDC], for both clients and resource servers.<br />
Examples of other clients (including [https://github.com/openid/AppAuth-JS Javascript], [https://github.com/openid/AppAuth-Android Android] and [https://github.com/openid/AppAuth-iOS iOS]), and servers (including [https://github.com/openid/ruby-openid Ruby] and [https://github.com/openid/php-openid PHP] can be found on the OpenID Github page, https://github.com/openid/ . For other clients, please get in touch if you have suggestions.<br />
<br />
== Example Tutorials ==<br />
<br />
Apart from the official documentation, there are also useful tutorials available online. Some are:<br />
* [https://patrick.uiterwijk.org/ Patrick Uiterwjk] [https://pythonhosted.org/python-fedora/flask_fas_openid.html FAS Flask OpenID Auth Plugin]<br />
* [http://www.mattmakai.com/ Matt Makai], [https://www.fullstackpython.com/blog/add-user-authentication-flask-apps-okta.html How to Add User Authentication to Flask Apps with Okta]<br />
* [https://developer.okta.com/blog/authors/randall-degges/ Randall Degges] [https://developer.okta.com/blog/2018/07/12/flask-tutorial-simple-user-registration-and-login Flask Tutorial: Simple User Registration and Login]<br />
* [https://fedoraproject.org/wiki/User:Pingou Pierre-Yves Chibon] [https://fpdc-client.readthedocs.io/en/latest/userguide.html#authentication FPDC User guide: Authentication]<br />
<br />
<br />
An example authentication page is:<br />
<nowiki><br />
<br />
# An simple demonstration application to use Fedora OpenID<br />
# authentication system<br />
# setup a client secrets file by doing<br />
#<br />
# pip3 install oidc-register<br />
# oidc-register https://iddev.fedorainfracloud.org/openidc/ http://localhost:5000<br />
#<br />
# Then run the application, (save it as app.py)<br />
# flask run<br />
#<br />
# then open your browser at http://localhost:5000<br />
<br />
#imports for Flask<br />
import flask<br />
from fedora.client import AuthError, AppError<br />
from flask_oidc import OpenIDConnect<br />
import munch<br />
<br />
# Set up Flask application<br />
app = flask.Flask(__name__)<br />
# Application configuration (add secret key of your choice)<br />
app.config["OIDC_CLIENT_SECRETS"] = "client_secrets.json"<br />
app.config["SECRET_KEY"] = "secretkey"<br />
<br />
# Set up FAS extension<br />
OIDC = OpenIDConnect(app, credentials_store=flask.session)<br />
<br />
@app.before_request<br />
def before_request():<br />
"""Set the flask session as permanent."""<br />
flask.session.permanent = True<br />
# Check if already logged in<br />
if OIDC.user_loggedin:<br />
if not hasattr(flask.session, 'fas_user') or not flask.session.fas_user:<br />
flask.session.fas_user = munch.Munch({<br />
'username': OIDC.user_getfield('nickname'),<br />
'email': OIDC.user_getfield('email') or '',<br />
'cla_done':<br />
'http://admin.fedoraproject.org/accounts/cla/done'<br />
in (OIDC.user_getfield('cla') or []),<br />
})<br />
flask.g.user = flask.session.fas_user<br />
else:<br />
flask.g.fas_user = None<br />
flask.session.fas_user = None<br />
<br />
@app.route("/logged_in")<br />
@OIDC.require_login<br />
def logged_in():<br />
return flask.Response("You are now logged in. Try to logout by going to http://localhost:5000/logout")<br />
<br />
@app.route("/")<br />
def landing_page():<br />
return flask.Response("Landing page, try to go to http://localhost:5000/login")<br />
<br />
@app.route("/login")<br />
def login():<br />
return flask.redirect(flask.url_for('.logged_in'))<br />
<br />
@app.route("/logout")<br />
def logout():<br />
if hasattr(flask.g, 'fas_user') and flask.g.fas_user is not None:<br />
OIDC.logout()<br />
flask.g.fas_user = None<br />
flask.session.fas_user = None<br />
flask.flash('You have been logged out')<br />
return flask.redirect(flask.url_for('.landing_page'))<br />
</nowiki><br />
<br />
== Custom UserInfo fields ==<br />
{|class="wikitable"<br />
! Field !! Summary !! Scope required (check table below for the namespace of these scopes)<br />
|-<br />
| groups || List of groups the user is a member of || groups<br />
|-<br />
| cla || List of CLA URIs the user hs signed || cla<br />
|}<br />
<br />
== Scopes ==<br />
OAuth2/OpenID Connect scopes are specific strings that indicate for what use a particular token was requested.<br />
When a token is issued, the user was asked whether or not they consented to the particular set of permissions indicated by the token.<br />
For example, only tokens that were requested containing the scope <nowiki>https://release-monitoring.org/oidc/upstream</nowiki> can be used at Anitya<br />
for updating upstream project information.<br />
A token can contain many possible scopes, all of which have been authorized by the user.<br />
<br />
In the Fedora Infrastructure, various applications are defined that specify various possible token scopes.<br />
These scopes are recorded here.<br />
<br />
Every service will first list it's base namespace, and then the scope ID and a short summary of the scopes.<br />
To get the full scope to request, append the scope ID to the base namespace.<br />
So for example, to get the group information, this becomes: <nowiki>https://id.fedoraproject.org/scope/groups</nowiki><br />
<br />
The "Availability" line indicates whether this scope is live on the development, staging and production identity provider.<br />
A scope might not have progressed further because the application implementing it is only in a certain stage of development.<br />
This should only be edited by the infrastructure member that progresses the scope out further.<br />
<br />
=== Registering new scopes ===<br />
To register a new set of scopes, please feel free to just create a new section and then file a ticket on https://pagure.io/fedora-infrastructure/ to get them added to the development instance.<br />
<br />
Also, once the scopes are finalized, please open a second ticket on https://pagure.io/fedora-infrastructure/ to request the scopes be added to the staging/production systems.<br />
<br />
To add new scopes to an existing project, add a second table with the new scopes to the relevant section, follow the above process, and then merge the two tables back into one after the scopes are fully deployed.<br />
<br />
=== Standard ===<br />
These scopes are standardized, and not namespaced.<br />
<br />
Availability: Development, Staging, Production.<br />
<br />
{|class="wikitable"<br />
! Scope ID !! Claims provided<br />
|- <br />
| openid || - This one is *required* for OpenID Connect requests<br />
|- <br />
| profile || name, nickname, preferred_nickname, profile, zoneinfo, locale, updated_at<br />
|-<br />
| email || email<br />
|}<br />
<br />
=== Ipsilon ===<br />
Base namespace: <nowiki>https://id.fedoraproject.org/scope/</nowiki><br />
<br />
Availability: Development, Staging, Production.<br />
<br />
{|class="wikitable"<br />
! Scope ID !! Summary<br />
|- <br />
| groups || Provides the "groups" attribute in the User Info.<br />
|-<br />
| cla || Provides the "cla" attribute in the User Info.<br />
|}<br />
<br />
=== release-monitoring.org ===<br />
Base namespace: <nowiki>https://release-monitoring.org/oidc/</nowiki><br />
<br />
Note: release-monitoring.org is used here in the sense of "the upstream project that maintains the Anitya software", and hence these scope names are used regardless of where any given Anitya instance is deployed<br />
<br />
Availability: Development<br />
<br />
{|class="wikitable"<br />
! Scope ID !! Summary<br />
|- <br />
| upstream || Permission to register new upstream projects for monitoring<br />
|-<br />
| downstream || Permission to register new distros and new upstream/downstream mappings<br />
|}<br />
<br />
=== mbs.fedoraproject.org ===<br />
<br />
Base namespace: <nowiki>https://mbs.fedoraproject.org/oidc/</nowiki><br />
<br />
Availability: Staging, Production<br />
<br />
{|class="wikitable"<br />
! Scope ID !! Summary<br />
|- <br />
| submit-build || Permission to submit new module builds<br />
|}<br />
<br />
=== waiverdb.fedoraproject.org ===<br />
<br />
Base namespace: <nowiki>https://waiverdb.fedoraproject.org/oidc/</nowiki><br />
<br />
Availability: Development, Staging<br />
<br />
{|class="wikitable"<br />
! Scope ID !! Summary<br />
|- <br />
| create-waiver || Permission to create new waivers<br />
|}<br />
<br />
=== beaker.qa.fedoraproject.org ===<br />
<br />
Base namespace: <nowiki>https://beaker-project.org/oidc/</nowiki><br />
<br />
Availability: Staging, Production<br />
<br />
{|class="wikitable"<br />
! Scope ID !! Summary<br />
|- <br />
| scope || Full access to your beaker account.<br />
|}<br />
<br />
<br />
=== pagure.io/odcs ===<br />
<br />
Base namespace: <nowiki>https://pagure.io/odcs/</nowiki><br />
<br />
Availability: Development,Staging,Production<br />
<br />
{|class="wikitable"<br />
! Scope ID !! Summary<br />
|- <br />
| new-compose || Permission to create a new compose<br />
|-<br />
| renew-compose || Permission to renew a compose<br />
|-<br />
| delete-compose || Permission to delete a compose<br />
|}<br />
<br />
<br />
=== github.com/fedora-infra/bodhi ===<br />
<br />
Base namespace: <nowiki>https://github.com/fedora-infra/bodhi/</nowiki><br />
<br />
Availability:<br />
<br />
{|class="wikitable"<br />
! Scope ID !! Summary<br />
|- <br />
| comment || Post new comments and votes<br />
|- <br />
| create-update || Submit new updates<br />
|- <br />
| edit-update || Edit updates<br />
|- <br />
| request-update || Request batched or stable<br />
|- <br />
| revoke-update || Revoke an update<br />
|- <br />
| create-override || Submit new override<br />
|- <br />
| edit-override || Edit override<br />
|- <br />
| expire-override || Expire an override<br />
|}<br />
<br />
<br />
=== fedoraproject.org/wiki ===<br />
<br />
Base namespace: <nowiki>https://fedoraproject.org/wiki/</nowiki><br />
<br />
Availability: Staging, Production<br />
<br />
{|class="wikitable"<br />
! Scope ID !! Summary<br />
|- <br />
| api || Full API access<br />
|}<br />
<br />
=== pagure.io/freshmaker ===<br />
<br />
Base namespace: <nowiki>https://pagure.io/freshmaker/</nowiki><br />
<br />
Availability: Staging,Production<br />
<br />
{|class="wikitable"<br />
! Scope ID !! Summary<br />
|- <br />
| submit-build || Permission to trigger manual rebuilds<br />
|}<br />
<br />
=== src.fedoraproject.org ===<br />
<br />
Base namespace: <nowiki>https://src.fedoraproject.org/</nowiki><br />
<br />
Availability: Staging,Production<br />
<br />
{|class="wikitable"<br />
! Scope ID !! Summary<br />
|- <br />
| push || Perform git pushes<br />
|}<br />
<br />
=== pagure.io ===<br />
<br />
Base namespace: <nowiki>https://pagure.io/oidc/</nowiki><br />
<br />
Availability: Development<br />
<br />
{| class="wikitable"<br />
|-<br />
! Scope ID !! Summary<br />
|-<br />
| pull_request_merge || Permission to merge a pull-request<br />
|-<br />
| pull_request_close || Permission to close a pull-request<br />
|-<br />
| pull_request_comment || Permission to comment a pull-request<br />
|-<br />
| pull_request_flag || Permission to flag a pull-request with a CI status<br />
|-<br />
| pull_request_subscribe || Permission to subscribe a user to a pull-request<br />
|-<br />
| pull_request_create || Permission to create a pull-request<br />
|-<br />
| issue_create || Permission to create an issue<br />
|-<br />
| issue_update || Permission to update an issue<br />
|-<br />
| issue_change_status || Permission to change the status of an issue<br />
|-<br />
| issue_update_milestone || Permission to update the milestone of an issue<br />
|-<br />
| issue_comment || Permission to comment on an issue<br />
|-<br />
| issue_assign || Permission to assign an issue to a user<br />
|-<br />
| issue_subscribe || Permission to subscribe a user to an issue <br />
|-<br />
| issue_update_custom_fields || Permission to update an issue custom fields<br />
|-<br />
| create_project || Permission to create a project<br />
|-<br />
| modify_project || Permission to modify a project<br />
|-<br />
| fork_project || Permission to fork a project<br />
|-<br />
| generate_acls_project || Permission to generate the gitolite ACLs of a project<br />
|-<br />
| commit_flag || Permission to flag a commit with a CI results<br />
|}<br />
<br />
=== fpdc.fedoraproject.org ===<br />
<br />
Base namespace: <nowiki>https://fpdc.fedoraproject.org/oidc/</nowiki><br />
<br />
Availability: Development,Staging,Production<br />
{| class="wikitable"<br />
|-<br />
! Scope ID !! Summary<br />
|-<br />
| create-release || Create a Release record<br />
|-<br />
| update-release || Edit a Release record<br />
|-<br />
| delete-release || Delete a Release record<br />
|}<br />
<br />
<br />
=== github.com/jmflinuxtx/kerneltest-harness ===<br />
<br />
Base namespace: <nowiki>https://github.com/jmflinuxtx/kerneltest-harness/oidc/</nowiki><br />
<br />
Availability:<br />
<br />
{|class="wikitable"<br />
! Scope ID !! Summary<br />
|- <br />
| upload_test_run || Upload the results of a test run<br />
|}</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Changes/Signed_RPM_Contents&diff=599677Changes/Signed RPM Contents2021-01-05T16:50:49Z<p>Puiterwijk: </p>
<hr />
<div>= Signed RPM Contents =<br />
<br />
== Summary ==<br />
We want to add signatures to individual files that are part of shipped RPMs.<br />
These signatures will use the Linux IMA (Integrity Measurement Architecture) scheme, which means they can be used to enforce runtime policies to ensure execution of only trusted files.<br />
<br />
== Owner ==<br />
* Name: [[User:Puiterwijk| Patrick Uiterwijk]]<br />
* Email: puiterwijk@redhat.com<br />
* Name: [[User:Pbrobinson| Peter Robinson]]<br />
* Email: pbrobinson@gmail.com<br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<br />
== Current status ==<br />
[[Category:ChangeReadyForWrangler]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
[[Category:SystemWideChange]]<br />
<br />
* Targeted release: [[Releases/34 | Fedora 34 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
ASSIGNED -> accepted by FESCo with ongoing development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* FESCo issue: <will be assigned by the Wrangler><br />
* Tracker bug: <will be assigned by the Wrangler><br />
* Release notes tracker: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
During signing builds, the files in it will be signed with IMA signatures..<br />
These signatures will be made with a key that’s kept by the Fedora Infrastructure team, and installed on the sign vaults.<br />
<br />
== Feedback ==<br />
<br />
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. --><br />
<br />
== Benefit to Fedora ==<br />
<br />
Having all files signed with a verifiable key means that system owners can use the kernel Integrity and Measurement Architecture (IMA) to enforce only verified files can be executed, or define other policies.<br />
<br />
== Scope ==<br />
* Proposal owners:<br />
The proposal owners will write the code for sigul to pass the required arguments, generate the keys in Infrastructure and get them deployed to the sign vaults.<br />
<br />
* Other developers:<br />
Nothing needed from other developers<br />
<br />
* Release engineering: <br />
A mass rebuild would be nice (as it ensures all packages are signed), but is not required to implement the change itself.<br />
<br />
* Policies and guidelines:<br />
No impact<br />
<br />
* Trademark approval: <br />
No impact<br />
<br />
* Alignment with Objectives: <br />
This aligns with the Internet of Things objective.<br />
<br />
== Upgrade/compatibility impact ==<br />
For standard Fedora users there will be no impact. If an advanced user was already signing their own files (for the Fedora shipped RPMs) for IMA functionality, they will just overwrite the existing signature.<br />
<br />
== How To Test ==<br />
The signatures can be tested “in vitro” by running `evmctl ima_verify --sigfile --key publiccert.der -v myfile.txt`.<br />
This should result in the system reporting “<filename>: verification is OK”.<br />
The full system could be tested by enrolling the Fedora IMA key to the kernel `_ima` keyring, and adding a policy that verifies (some) files to be verified against the key. (instructions to follow).<br />
<br />
== User Experience ==<br />
If the user deploys an IMA policy to verify all or some files, they should be able to trust the signatures made by the Fedora build system.<br />
<br />
== Dependencies ==<br />
No external package dependencies.<br />
<br />
== Contingency Plan ==<br />
<br />
* Contingency mechanism: If the change is not finished in time, we have probably not yet started signing new files. Signing can easily be disabled by updating the config file should issues arise.<br />
If we did start signing, but haven’t signed everything, that is okay, since then packages will get signed as they’re bumped by developers, and they’ll be all signed in the next major release.<br />
<br />
* Contingency deadline: We could ship with this feature in an unfinished state.<br />
* Blocks release? No<br />
* Blocks product? N/A<br />
<br />
== Documentation ==<br />
Documentation to follow.<br />
<br />
== Release Notes ==</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Changes/Signed_RPM_Contents&diff=599676Changes/Signed RPM Contents2021-01-05T16:48:07Z<p>Puiterwijk: /* Contingency Plan */</p>
<hr />
<div>= Signed RPM Contents =<br />
<br />
== Summary ==<br />
We want to add signatures to individual files that are part of shipped RPMs.<br />
These signatures will use the Linux IMA (Integrity Measurement Architecture) scheme, which means they can be used to enforce runtime policies to ensure execution of only trusted files.<br />
<br />
== Owner ==<br />
* Name: [[User:Puiterwijk| Patrick Uiterwijk]]<br />
* Email: puiterwijk@redhat.com<br />
* Name: [[User:Pbrobinson| Peter Robinson]]<br />
* Email: pbrobinson@gmail.com<br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<br />
== Current status ==<br />
[[Category:ChangePageIncomplete]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
[[Category:SystemWideChange]]<br />
<br />
* Targeted release: [[Releases/34 | Fedora 34 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
ASSIGNED -> accepted by FESCo with ongoing development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* FESCo issue: <will be assigned by the Wrangler><br />
* Tracker bug: <will be assigned by the Wrangler><br />
* Release notes tracker: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
During signing builds, the files in it will be signed with IMA signatures..<br />
These signatures will be made with a key that’s kept by the Fedora Infrastructure team, and installed on the sign vaults.<br />
<br />
== Feedback ==<br />
<br />
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. --><br />
<br />
== Benefit to Fedora ==<br />
<br />
Having all files signed with a verifiable key means that system owners can use the kernel Integrity and Measurement Architecture (IMA) to enforce only verified files can be executed, or define other policies.<br />
<br />
== Scope ==<br />
* Proposal owners:<br />
The proposal owners will write the code for sigul to pass the required arguments, generate the keys in Infrastructure and get them deployed to the sign vaults.<br />
<br />
* Other developers:<br />
Nothing needed from other developers<br />
<br />
* Release engineering: <br />
A mass rebuild would be nice (as it ensures all packages are signed), but is not required to implement the change itself.<br />
<br />
* Policies and guidelines:<br />
No impact<br />
<br />
* Trademark approval: <br />
No impact<br />
<br />
* Alignment with Objectives: <br />
This aligns with the Internet of Things objective.<br />
<br />
== Upgrade/compatibility impact ==<br />
For standard Fedora users there will be no impact. If an advanced user was already signing their own files (for the Fedora shipped RPMs) for IMA functionality, they will just overwrite the existing signature.<br />
<br />
== How To Test ==<br />
The signatures can be tested “in vitro” by running `evmctl ima_verify --sigfile --key publiccert.der -v myfile.txt`.<br />
This should result in the system reporting “<filename>: verification is OK”.<br />
The full system could be tested by enrolling the Fedora IMA key to the kernel `_ima` keyring, and adding a policy that verifies (some) files to be verified against the key. (instructions to follow).<br />
<br />
== User Experience ==<br />
If the user deploys an IMA policy to verify all or some files, they should be able to trust the signatures made by the Fedora build system.<br />
<br />
== Dependencies ==<br />
No external package dependencies.<br />
<br />
== Contingency Plan ==<br />
<br />
* Contingency mechanism: If the change is not finished in time, we have probably not yet started signing new files. Signing can easily be disabled by updating the config file should issues arise.<br />
If we did start signing, but haven’t signed everything, that is okay, since then packages will get signed as they’re bumped by developers, and they’ll be all signed in the next major release.<br />
<br />
* Contingency deadline: We could ship with this feature in an unfinished state.<br />
* Blocks release? No<br />
* Blocks product? N/A<br />
<br />
== Documentation ==<br />
Documentation to follow.<br />
<br />
== Release Notes ==</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Changes/Signed_RPM_Contents&diff=599675Changes/Signed RPM Contents2021-01-05T16:45:22Z<p>Puiterwijk: </p>
<hr />
<div>= Signed RPM Contents =<br />
<br />
== Summary ==<br />
We want to add signatures to individual files that are part of shipped RPMs.<br />
These signatures will use the Linux IMA (Integrity Measurement Architecture) scheme, which means they can be used to enforce runtime policies to ensure execution of only trusted files.<br />
<br />
== Owner ==<br />
* Name: [[User:Puiterwijk| Patrick Uiterwijk]]<br />
* Email: puiterwijk@redhat.com<br />
* Name: [[User:Pbrobinson| Peter Robinson]]<br />
* Email: pbrobinson@gmail.com<br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<br />
== Current status ==<br />
[[Category:ChangePageIncomplete]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
[[Category:SystemWideChange]]<br />
<br />
* Targeted release: [[Releases/34 | Fedora 34 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
ASSIGNED -> accepted by FESCo with ongoing development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* FESCo issue: <will be assigned by the Wrangler><br />
* Tracker bug: <will be assigned by the Wrangler><br />
* Release notes tracker: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
During signing builds, the files in it will be signed with IMA signatures..<br />
These signatures will be made with a key that’s kept by the Fedora Infrastructure team, and installed on the sign vaults.<br />
<br />
== Feedback ==<br />
<br />
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. --><br />
<br />
== Benefit to Fedora ==<br />
<br />
Having all files signed with a verifiable key means that system owners can use the kernel Integrity and Measurement Architecture (IMA) to enforce only verified files can be executed, or define other policies.<br />
<br />
== Scope ==<br />
* Proposal owners:<br />
The proposal owners will write the code for sigul to pass the required arguments, generate the keys in Infrastructure and get them deployed to the sign vaults.<br />
<br />
* Other developers:<br />
Nothing needed from other developers<br />
<br />
* Release engineering: <br />
A mass rebuild would be nice (as it ensures all packages are signed), but is not required to implement the change itself.<br />
<br />
* Policies and guidelines:<br />
No impact<br />
<br />
* Trademark approval: <br />
No impact<br />
<br />
* Alignment with Objectives: <br />
This aligns with the Internet of Things objective.<br />
<br />
== Upgrade/compatibility impact ==<br />
For standard Fedora users there will be no impact. If an advanced user was already signing their own files (for the Fedora shipped RPMs) for IMA functionality, they will just overwrite the existing signature.<br />
<br />
== How To Test ==<br />
The signatures can be tested “in vitro” by running `evmctl ima_verify --sigfile --key publiccert.der -v myfile.txt`.<br />
This should result in the system reporting “<filename>: verification is OK”.<br />
The full system could be tested by enrolling the Fedora IMA key to the kernel `_ima` keyring, and adding a policy that verifies (some) files to be verified against the key. (instructions to follow).<br />
<br />
== User Experience ==<br />
If the user deploys an IMA policy to verify all or some files, they should be able to trust the signatures made by the Fedora build system.<br />
<br />
== Dependencies ==<br />
No external package dependencies.<br />
<br />
== Contingency Plan ==<br />
<br />
* Contingency mechanism: If the change is not finished in time, we have probably not yet started signing new files. If we did start signing files and something went awry, we can back out the sigul configuration to sign files.<br />
If we did start signing, but haven’t signed everything, that is okay, since then packages will get signed as they’re bumped by developers, and they’ll be all signed in the next major release.<br />
<br />
* Contingency deadline: We could ship with this feature in an unfinished state.<br />
* Blocks release? No<br />
* Blocks product? N/A<br />
<br />
== Documentation ==<br />
Documentation to follow.<br />
<br />
== Release Notes ==</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Changes/Signed_RPM_Contents&diff=599674Changes/Signed RPM Contents2021-01-05T16:42:30Z<p>Puiterwijk: Update with new approach</p>
<hr />
<div>= Signed RPM Contents =<br />
<br />
== Summary ==<br />
We want to add signatures to individual files that are part of shipped RPMs.<br />
These signatures will use the Linux IMA (Integrity Measurement Architecture) scheme, which means they can be used to enforce runtime policies to ensure execution of only trusted files.<br />
<br />
== Owner ==<br />
* Name: [[User:Puiterwijk| Patrick Uiterwijk]]<br />
* Email: puiterwijk@redhat.com<br />
* Name: [[User:Pbrobinson| Peter Robinson]]<br />
* Email: pbrobinson@gmail.com<br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<br />
== Current status ==<br />
[[Category:ChangePageIncomplete]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
[[Category:SystemWideChange]]<br />
<br />
* Targeted release: [[Releases/34 | Fedora 34 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
ASSIGNED -> accepted by FESCo with ongoing development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* FESCo issue: <will be assigned by the Wrangler><br />
* Tracker bug: <will be assigned by the Wrangler><br />
* Release notes tracker: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
During signing builds, the files in it will be signed with IMA signatures..<br />
These signatures will be made with a key that’s kept by the Fedora Infrastructure team, and installed on the sign vaults.<br />
<br />
== Feedback ==<br />
<br />
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. --><br />
<br />
== Benefit to Fedora ==<br />
<br />
Having all files signed with a verifiable key means that system owners can use the kernel Integrity and Measurement Architecture (IMA) to enforce only verified files can be executed, or define other policies.<br />
<br />
== Scope ==<br />
* Proposal owners:<br />
The proposal owners will write the code for sigul to pass the required arguments, generate the keys in Infrastructure and get them deployed to the sign vaults.<br />
<br />
* Other developers:<br />
Nothing needed from other developers<br />
<br />
* Release engineering: <br />
A mass rebuild would be nice (as it ensures all packages are signed), but is not required to implement the change itself.<br />
<br />
* Policies and guidelines:<br />
No impact<br />
<br />
* Trademark approval: <br />
No impact<br />
<br />
* Alignment with Objectives: <br />
This aligns with the Internet of Things objective.<br />
<br />
== Upgrade/compatibility impact ==<br />
There should be little to no impact on existing systems. If a user was already signing their own files, they will just overwrite the existing signature. If they weren’t, this adds a new extended attribute (if RPM was not asked to skip that), that is unused until they deploy an IMA policy that uses it.<br />
<br />
== How To Test ==<br />
The signatures can be tested “in vitro” by running `evmctl ima_verify --sigfile --key publiccert.der -v myfile.txt`.<br />
This should result in the system reporting “<filename>: verification is OK”.<br />
The full system could be tested by enrolling the Fedora IMA key to the kernel `_ima` keyring, and adding a policy that verifies (some) files to be verified against the key. (instructions to follow).<br />
<br />
== User Experience ==<br />
If the user deploys an IMA policy to verify all or some files, they should be able to trust the signatures made by the Fedora build system.<br />
<br />
== Dependencies ==<br />
No external package dependencies.<br />
<br />
== Contingency Plan ==<br />
<br />
* Contingency mechanism: If the change is not finished in time, we have probably not yet started signing new files. If we did start signing files and something went awry, we can back out the sigul configuration to sign files.<br />
If we did start signing, but haven’t signed everything, that is okay, since then packages will get signed as they’re bumped by developers, and they’ll be all signed in the next major release.<br />
<br />
* Contingency deadline: We could ship with this feature in an unfinished state.<br />
* Blocks release? No<br />
* Blocks product? N/A<br />
<br />
== Documentation ==<br />
Documentation to follow.<br />
<br />
== Release Notes ==</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Changes/Signed_RPM_Contents&diff=599606Changes/Signed RPM Contents2021-01-04T15:20:07Z<p>Puiterwijk: Initial draft</p>
<hr />
<div>= Signed RPM Contents =<br />
<br />
== Summary ==<br />
We want to add signatures to individual files that are part of shipped RPMs.<br />
These signatures will use the Linux IMA (Integrity Measurement Architecture) scheme, which means they can be used to enforce runtime policies to ensure execution of only trusted files.<br />
<br />
== Owner ==<br />
* Name: [[User:Puiterwijk| Patrick Uiterwijk]]<br />
* Email: puiterwijk@redhat.com<br />
* Name: [[User:Pbrobinson| Peter Robinson]]<br />
* Email: pbrobinson@gmail.com<br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<br />
== Current status ==<br />
[[Category:ChangePageIncomplete]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
[[Category:SystemWideChange]]<br />
<br />
* Targeted release: [[Releases/34 | Fedora 34 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
ASSIGNED -> accepted by FESCo with ongoing development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* FESCo issue: <will be assigned by the Wrangler><br />
* Tracker bug: <will be assigned by the Wrangler><br />
* Release notes tracker: <will be assigned by the Wrangler><br />
<br />
== Detailed Description ==<br />
<br />
During builds of non-scratch builds, the contents will be signed before they’re embedded in the built RPM file.<br />
These signatures will be made with a key that’s kept by the Fedora Infrastructure team, and injected into the builders’ kernel keyrings before they start building.<br />
After this, an RPM script will automatically use the key to sign the files in the %files list of the RPM package, after which these signatures will be picked up by RPM to be installed on the destination system in the IMA extended file attribute.<br />
<br />
== Feedback ==<br />
<br />
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. --><br />
<br />
== Benefit to Fedora ==<br />
<br />
Having all files signed with a verifiable key means that system owners can use the kernel Integrity and Measurement Architecture (IMA) to enforce only verified files can be executed, or define other policies.<br />
<br />
== Scope ==<br />
* Proposal owners:<br />
The proposal owners will write code to sign the files, and a script to automatically sign files during the RPM install phase.<br />
<br />
* Other developers:<br />
Nothing needed from other developers<br />
<br />
* Release engineering: <br />
A mass rebuild would be nice (as it ensures all packages are signed), but is not required to implement the change itself.<br />
<br />
* Policies and guidelines:<br />
No impact<br />
<br />
* Trademark approval: <br />
No impact<br />
<br />
* Alignment with Objectives: <br />
This aligns with the Internet of Things objective.<br />
<br />
== Upgrade/compatibility impact ==<br />
There should be little to no impact on existing systems. If a user was already signing their own files, they will just overwrite the existing signature. If they weren’t, this adds a new extended attribute (if RPM was not asked to skip that), that is unused until they deploy an IMA policy that uses it.<br />
<br />
== How To Test ==<br />
The signatures can be tested “in vitro” by running `evmctl ima_verify --sigfile --key publiccert.der -v myfile.txt`.<br />
This should result in the system reporting “<filename>: verification is OK”.<br />
The full system could be tested by enrolling the Fedora IMA key to the kernel `_ima` keyring, and adding a policy that verifies (some) files to be verified against the key. (instructions to follow).<br />
<br />
== User Experience ==<br />
If the user deploys an IMA policy to verify all or some files, they should be able to trust the signatures made by the Fedora build system.<br />
<br />
== Dependencies ==<br />
No external package dependencies.<br />
<br />
== Contingency Plan ==<br />
<br />
* Contingency mechanism: If the change is not finished in time, we have probably not yet started signing new files. If we did start signing files and something went awry, we can back out the RPM build script that signs files.<br />
If we did start signing, but haven’t signed everything, that is okay, since then packages will get signed as they’re bumped by developers, and they’ll be all signed in the next major release.<br />
<br />
* Contingency deadline: We could ship with this feature in an unfinished state.<br />
* Blocks release? No<br />
* Blocks product? N/A<br />
<br />
== Documentation ==<br />
Documentation to follow.<br />
<br />
== Release Notes ==</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Changes/PARSEC&diff=581376Changes/PARSEC2020-07-06T09:14:09Z<p>Puiterwijk: Add puiterwijk as co-owner</p>
<hr />
<div>= Support PARSEC =<br />
<br />
== Summary ==<br />
PARSEC is the Platform AbstRaction for SECurity, an open-source initiative to provide a common API to hardware security and cryptographic services in a platform-agnostic way. This abstraction layer keeps workloads decoupled from physical platform details, enabling cloud-native delivery flows within the data center and at the edge.<br />
From a hardware perspective the PARSEC daemon can currerntly use a TPM2, HSM or an Arm TrustZone secure world application.<br />
<br />
== Owner ==<br />
* Name: [[User:pbrobinson| Peter Robinson]], [[User:puiterwijk | Patrick Uiterwijk]]<br />
* Email: [mailto:pbrobinson@gmail.com| pbrobinson@gmail.com], [mailto:patrick@puiterwijk.org | patrick@puiterwijk.org]<br />
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --><br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/33 | Fedora 33 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -> change proposal is submitted and announced<br />
ASSIGNED -> accepted by FESCo with on going development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* Tracker bug:<br />
<br />
== Detailed Description ==<br />
<br />
PARSEC (Platform AbstRaction for SECurity) is an initiative started out of Arm to provide a straight forward API for accessing secure credentials stored in hardware. It's a sandbox project in the CNCF.<br />
<br />
== Benefit to Fedora ==<br />
<br />
PARSEC is a useful technology for Fedora because making HW security technologies appear seemless to applications and users helps make security more straight forward and secure overall. It's a relative new initiative and having it available in Fedora for people to start to integrate into their applications helps make Fedora a leader in security in particular for Internet of Things and Device Edge. The IoT Edition will be using PARSEC.<br />
<br />
== Scope ==<br />
* Proposal owners:<br />
** Package the PARSEC daemon, libraries and language bindings.<br />
<br />
* Other developers: <br />
** No impact but developers may wish to add support for PARSEC to their application.<br />
<br />
* Release engineering: [https://pagure.io/releng/issue/XXX #XXX]<br />
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Please check the list of Fedora release deliverables and list all the differences the feature brings --><br />
<br />
* Policies and guidelines: N/A (not a System Wide Change)<br />
<br />
* Trademark approval: N/A (not needed for this Change)<br />
<br />
== Upgrade/compatibility impact ==<br />
This is net new to Fedora so there is no upgrade issues.<br />
<br />
== How To Test ==<br />
<br />
There's a number of hardware options for testing. Any device with a TPM2 including most modern laptops.<br />
<br />
There will be selection of Arm devices available (final models still TBD) with the appropriate firmware running the TrustZone secure world application.<br />
<br />
A VM with a swTPM, while not secure, will enable testing.<br />
<br />
A number of HW security modules, exact devices still TBD.<br />
<br />
== User Experience ==<br />
There will be a new daemon start in the early boot process for those that install the PARSEC stack. Fedora IoT Edition will install and start this by default.<br />
<br />
The Red Hat Device Edge team and Arm are working on a demo application for IoT to provide a demonstration application on the technology.<br />
<br />
== Dependencies ==<br />
N/A (not a System Wide Change) <br />
<br />
== Contingency Plan ==<br />
<br />
* Contingency mechanism: Most of the work here is packaging so if it doesn't make the release it would be available as an installable update.<br />
* Contingency deadline: N/A (not a System Wide Change)<br />
* Blocks release? No.<br />
* Blocks product? No.<br />
<br />
== Documentation ==<br />
N/A (not a System Wide Change) <br />
<br />
== Release Notes ==<br />
<br />
<br />
[[Category:ChangePageIncomplete]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
[[Category:SelfContainedChange]]<br />
<!-- [[Category:SystemWideChange]] --></div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Changes/PARSEC&diff=581374Changes/PARSEC2020-07-06T09:12:27Z<p>Puiterwijk: Update Summary to include what it does</p>
<hr />
<div>= Support PARSEC =<br />
<br />
== Summary ==<br />
PARSEC is the Platform AbstRaction for SECurity, an open-source initiative to provide a common API to hardware security and cryptographic services in a platform-agnostic way. This abstraction layer keeps workloads decoupled from physical platform details, enabling cloud-native delivery flows within the data center and at the edge.<br />
From a hardware perspective the PARSEC daemon can currerntly use a TPM2, HSM or an Arm TrustZone secure world application.<br />
<br />
== Owner ==<br />
* Name: [[User:pbrobinson| Peter Robinson]]<br />
* Email: [mailto:pbrobinson@gmail.com| pbrobinson@gmail.com]<br />
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --><br />
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)<br />
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address><br />
--><br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/33 | Fedora 33 ]] <br />
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} <br />
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page <br />
Bugzilla states meaning as usual:<br />
NEW -> change proposal is submitted and announced<br />
ASSIGNED -> accepted by FESCo with on going development<br />
MODIFIED -> change is substantially done and testable<br />
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)<br />
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development<br />
--><br />
* Tracker bug:<br />
<br />
== Detailed Description ==<br />
<br />
PARSEC (Platform AbstRaction for SECurity) is an initiative started out of Arm to provide a straight forward API for accessing secure credentials stored in hardware. It's a sandbox project in the CNCF.<br />
<br />
== Benefit to Fedora ==<br />
<br />
PARSEC is a useful technology for Fedora because making HW security technologies appear seemless to applications and users helps make security more straight forward and secure overall. It's a relative new initiative and having it available in Fedora for people to start to integrate into their applications helps make Fedora a leader in security in particular for Internet of Things and Device Edge. The IoT Edition will be using PARSEC.<br />
<br />
== Scope ==<br />
* Proposal owners:<br />
** Package the PARSEC daemon, libraries and language bindings.<br />
<br />
* Other developers: <br />
** No impact but developers may wish to add support for PARSEC to their application.<br />
<br />
* Release engineering: [https://pagure.io/releng/issue/XXX #XXX]<br />
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --><br />
<!-- Please check the list of Fedora release deliverables and list all the differences the feature brings --><br />
<br />
* Policies and guidelines: N/A (not a System Wide Change)<br />
<br />
* Trademark approval: N/A (not needed for this Change)<br />
<br />
== Upgrade/compatibility impact ==<br />
This is net new to Fedora so there is no upgrade issues.<br />
<br />
== How To Test ==<br />
<br />
There's a number of hardware options for testing. Any device with a TPM2 including most modern laptops.<br />
<br />
There will be selection of Arm devices available (final models still TBD) with the appropriate firmware running the TrustZone secure world application.<br />
<br />
A VM with a swTPM, while not secure, will enable testing.<br />
<br />
A number of HW security modules, exact devices still TBD.<br />
<br />
== User Experience ==<br />
There will be a new daemon start in the early boot process for those that install the PARSEC stack. Fedora IoT Edition will install and start this by default.<br />
<br />
The Red Hat Device Edge team and Arm are working on a demo application for IoT to provide a demonstration application on the technology.<br />
<br />
== Dependencies ==<br />
N/A (not a System Wide Change) <br />
<br />
== Contingency Plan ==<br />
<br />
* Contingency mechanism: Most of the work here is packaging so if it doesn't make the release it would be available as an installable update.<br />
* Contingency deadline: N/A (not a System Wide Change)<br />
* Blocks release? No.<br />
* Blocks product? No.<br />
<br />
== Documentation ==<br />
N/A (not a System Wide Change) <br />
<br />
== Release Notes ==<br />
<br />
<br />
[[Category:ChangePageIncomplete]]<br />
<!-- When your change proposal page is completed and ready for review and announcement --><br />
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --><br />
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) --> <br />
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete--><br />
<br />
<!-- Select proper category, default is Self Contained Change --><br />
[[Category:SelfContainedChange]]<br />
<!-- [[Category:SystemWideChange]] --></div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Infrastructure/Mirroring/Amazon&diff=546686Infrastructure/Mirroring/Amazon2019-06-30T12:17:36Z<p>Puiterwijk: Puiterwijk moved page Infrastructure/Mirroring/Amazon to Archive:Infrastructure/Mirroring/Amazon</p>
<hr />
<div>#REDIRECT [[Archive:Infrastructure/Mirroring/Amazon]]</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Archive:Infrastructure/Mirroring/Amazon&diff=546685Archive:Infrastructure/Mirroring/Amazon2019-06-30T12:17:36Z<p>Puiterwijk: Puiterwijk moved page Infrastructure/Mirroring/Amazon to Archive:Infrastructure/Mirroring/Amazon</p>
<hr />
<div>{{admon/warning|This page was a draft proposal from a long time ago. This is kept for posterity, but users should not use the URLs in this page. Please use mirrorlist for all repo configurations.}}<br />
<br />
<br />
Initial thoughts by Matt Domsch<br />
<br />
* Use Reduced Redundancy Storage. All the content will be replicated easily.<br />
* Use s3cmd sync to keep content in buckets in sync<br />
* see exclude list below<br />
* Use bucket policies to limit access to each region (if needed; not implemented yet)<br />
* Need list of IP addresses for each region to populate MM. Would be nice if we could get that programmatically.<br />
** https://forums.aws.amazon.com/ann.jspa?annID=1453<br />
** This moves around, so start there, then go to Forums, Elastic Compute Cloud, and look for the sticky thread.<br />
* syncing from bapp01 at present because it has r/o access to the trees<br />
<br />
* bucket names s3-mirror-<region>.fedoraproject.org allow for CNAME s3-mirror.fedoraproject.org to s3.amazon.com in our DNS<br />
{|<br />
| Region || Region Server || Bucket Name || CNAME<br />
|-<br />
| US Standard || s3-website-us-east-1.amazonaws.com || s3-mirror-us-east-1.fedoraproject.org || s3-mirror-us-east-1.fedoraproject.org CNAME s3-mirror-us-east-1.fedoraproject.org.s3-website-us-east-1.amazonaws.com<br />
|-<br />
| US West (Oregon) Region || s3-website-us-west-2.amazonaws.com || s3-mirror-us-west-2.fedoraproject.org<br />
|-<br />
| US West (Northern California) Region || s3-website-us-west-1.amazonaws.com || s3-mirror-us-west-1.fedoraproject.org<br />
|-<br />
| EU (Ireland) Region || s3-website-eu-west-1.amazonaws.com<br />
|-<br />
| Asia Pacific (Singapore) Region || s3-website-ap-southeast-1.amazonaws.com<br />
|-<br />
| Asia Pacific (Tokyo) Region || s3-website-ap-northeast-1.amazonaws.com<br />
|-<br />
| South America (Sao Paulo) Region || s3-website-sa-east-1.amazonaws.com<br />
|}<br />
<br />
<br />
** http://docs.amazonwebservices.com/AmazonS3/latest/dev/WebsiteEndpoints.html<br />
<br />
<br />
<br />
Torrents:<br />
* if we upload ISOs, we get .torrent links "for free".<br />
* no tracker stats :-(<br />
* Can't group multiple files together into a single torrent<br />
* we're paying for outbound bandwidth<br />
* bucket policies keeping traffic in a single region means we need separate buckets for torrent content<br />
<br />
<br />
<br />
Costs:<br />
* none for all uploads<br />
* none for intra-region requests<br />
* 0.093/GB/month for data, ~218GB = $20/month/region. 7 Regions, but start in US East 1 only for now.<br />
* a good number of PUT and LIST requests due to mirroring several times a day. Could be another $20/month just for those.<br />
* no way guess number of GET requests. $40 assumes 10M requests, while $30/month assumes 1M requests.<br />
Total: ~$280/month, or $3360/yr<br />
<br />
Open questions:<br />
* do we sync to one region, then COPY to others? If so, what tool? That'll cost $ for bandwidth.<br />
<br />
Proposed Excludes:<br />
<pre><br />
source/<br />
SRPMS/<br />
debug/<br />
beta/<br />
ppc/<br />
ppc64/<br />
repoview/<br />
Fedora/<br />
Live/<br />
isolinux/<br />
images/<br />
EFI/<br />
drpms/<br />
core/<br />
extras/<br />
LiveOS/<br />
updates/8<br />
updates/9<br />
updates/10<br />
updates/11<br />
updates/12<br />
updates/13<br />
updates/14<br />
updates/testing/8<br />
updates/testing/9<br />
updates/testing/10<br />
updates/testing/11<br />
updates/testing/12<br />
updates/testing/13<br />
updates/testing/14<br />
releases/test/<br />
</pre><br />
<br />
<br />
== Problems Encountered ==<br />
<br />
* s3cmd sync processes excludes after walking the whole local directory tree with os.walk(). This means it recurses over .snapshot/ and all the directories we want to exclude, increasing processing time by 20x (>700k files vs ~35k files we'll actually upload). Matt has an upstream pull request to fix this. https://github.com/s3tools/s3cmd/pull/27<br />
* On subsequent syncs, got this error from the /pub/epel tree:<br />
<pre><br />
ERROR: no element found: line 1, column 0<br />
ERROR: Parameter problem: Bucket contains invalid filenames. Please run: s3cmd fixbucket s3://your-bucket/<br />
</pre><br />
** This is caused by file names that have plus characters in their name.<br />
** Upstream bug: https://github.com/s3tools/s3cmd/issues/28<br />
** this doesn't impact the ability to download files from S3 URLs which have plus signs in their file name<br />
** Using urlencoding_mode=fixbucket does not work. Yum will download the file w/o URL encoding (e.g. with plus chars in the file name), and S3 won't return that file because it doesn't exist.<br />
* The MD5 checks don't happen at all for files uploaded via multipart, which seems to affect larger files. This defeats the purpose of MD5 checking. But, we can't disable MD5 checking for all files, because repomd.xml often changes content but doesn't change file size. So, we need MD5 checking only for some files.<br />
* turns out we need MD5 checking for package re-signing too. I guess we're stuck with using MD5 checking.<br />
** We could put additional custom metadata (e.g. RPM package field data) into S3 if we wanted to. That would make s3cmd more tailored to our use case.<br />
** It does store mtime/ctime values in the metadata. Need to add code to check those.<br />
* upload of initial bucket for EPEL took real 651m57.042s, /pub/fedora took real 892m52.286s.<br />
* subsequent syncs failed because of the above element error, but took 12m and 21m respectively (w/o transferring any changes due to the error)<br />
* MirrorManager's report_mirror program needs to be run after the sync, because this will be a private mirror. But, it also blindly does os.walk(), without a concept of excludes. Solutions are to either make a private copy of the whole content (ugh!), or add --exclude-from=<file> handling to report_mirror. Matt did the latter.<br />
* no hardlinks. Total /pub/epel and /pub/fedora trees take ~77GB. Bug filed https://github.com/s3tools/s3cmd/issues/29<br />
** If we use S3->S3 copy within one region, we can get 17-22MB/sec out of the copy, instead of ~700KB/sec doing uploads or S3->S3 inter-region copying. So let's get hardlinks working!!<br />
* no softlinks. This could pose a problem for EPEL consumers, where the version strings look like '4AS' which we've pointed at '4'. May be able to work around it with MM redirects.<br />
* No --delete-after option, deletes occur before new content is uploaded, which puts the repository into an inconsistent state during the upload. Matt has an upstream pull request to fix this: https://github.com/s3tools/s3cmd/pull/30</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Archive:Infrastructure/Mirroring/Amazon&diff=546684Archive:Infrastructure/Mirroring/Amazon2019-06-30T12:16:59Z<p>Puiterwijk: </p>
<hr />
<div>{{admon/warning|This page was a draft proposal from a long time ago. This is kept for posterity, but users should not use the URLs in this page. Please use mirrorlist for all repo configurations.}}<br />
<br />
<br />
Initial thoughts by Matt Domsch<br />
<br />
* Use Reduced Redundancy Storage. All the content will be replicated easily.<br />
* Use s3cmd sync to keep content in buckets in sync<br />
* see exclude list below<br />
* Use bucket policies to limit access to each region (if needed; not implemented yet)<br />
* Need list of IP addresses for each region to populate MM. Would be nice if we could get that programmatically.<br />
** https://forums.aws.amazon.com/ann.jspa?annID=1453<br />
** This moves around, so start there, then go to Forums, Elastic Compute Cloud, and look for the sticky thread.<br />
* syncing from bapp01 at present because it has r/o access to the trees<br />
<br />
* bucket names s3-mirror-<region>.fedoraproject.org allow for CNAME s3-mirror.fedoraproject.org to s3.amazon.com in our DNS<br />
{|<br />
| Region || Region Server || Bucket Name || CNAME<br />
|-<br />
| US Standard || s3-website-us-east-1.amazonaws.com || s3-mirror-us-east-1.fedoraproject.org || s3-mirror-us-east-1.fedoraproject.org CNAME s3-mirror-us-east-1.fedoraproject.org.s3-website-us-east-1.amazonaws.com<br />
|-<br />
| US West (Oregon) Region || s3-website-us-west-2.amazonaws.com || s3-mirror-us-west-2.fedoraproject.org<br />
|-<br />
| US West (Northern California) Region || s3-website-us-west-1.amazonaws.com || s3-mirror-us-west-1.fedoraproject.org<br />
|-<br />
| EU (Ireland) Region || s3-website-eu-west-1.amazonaws.com<br />
|-<br />
| Asia Pacific (Singapore) Region || s3-website-ap-southeast-1.amazonaws.com<br />
|-<br />
| Asia Pacific (Tokyo) Region || s3-website-ap-northeast-1.amazonaws.com<br />
|-<br />
| South America (Sao Paulo) Region || s3-website-sa-east-1.amazonaws.com<br />
|}<br />
<br />
<br />
** http://docs.amazonwebservices.com/AmazonS3/latest/dev/WebsiteEndpoints.html<br />
<br />
<br />
<br />
Torrents:<br />
* if we upload ISOs, we get .torrent links "for free".<br />
* no tracker stats :-(<br />
* Can't group multiple files together into a single torrent<br />
* we're paying for outbound bandwidth<br />
* bucket policies keeping traffic in a single region means we need separate buckets for torrent content<br />
<br />
<br />
<br />
Costs:<br />
* none for all uploads<br />
* none for intra-region requests<br />
* 0.093/GB/month for data, ~218GB = $20/month/region. 7 Regions, but start in US East 1 only for now.<br />
* a good number of PUT and LIST requests due to mirroring several times a day. Could be another $20/month just for those.<br />
* no way guess number of GET requests. $40 assumes 10M requests, while $30/month assumes 1M requests.<br />
Total: ~$280/month, or $3360/yr<br />
<br />
Open questions:<br />
* do we sync to one region, then COPY to others? If so, what tool? That'll cost $ for bandwidth.<br />
<br />
Proposed Excludes:<br />
<pre><br />
source/<br />
SRPMS/<br />
debug/<br />
beta/<br />
ppc/<br />
ppc64/<br />
repoview/<br />
Fedora/<br />
Live/<br />
isolinux/<br />
images/<br />
EFI/<br />
drpms/<br />
core/<br />
extras/<br />
LiveOS/<br />
updates/8<br />
updates/9<br />
updates/10<br />
updates/11<br />
updates/12<br />
updates/13<br />
updates/14<br />
updates/testing/8<br />
updates/testing/9<br />
updates/testing/10<br />
updates/testing/11<br />
updates/testing/12<br />
updates/testing/13<br />
updates/testing/14<br />
releases/test/<br />
</pre><br />
<br />
<br />
== Problems Encountered ==<br />
<br />
* s3cmd sync processes excludes after walking the whole local directory tree with os.walk(). This means it recurses over .snapshot/ and all the directories we want to exclude, increasing processing time by 20x (>700k files vs ~35k files we'll actually upload). Matt has an upstream pull request to fix this. https://github.com/s3tools/s3cmd/pull/27<br />
* On subsequent syncs, got this error from the /pub/epel tree:<br />
<pre><br />
ERROR: no element found: line 1, column 0<br />
ERROR: Parameter problem: Bucket contains invalid filenames. Please run: s3cmd fixbucket s3://your-bucket/<br />
</pre><br />
** This is caused by file names that have plus characters in their name.<br />
** Upstream bug: https://github.com/s3tools/s3cmd/issues/28<br />
** this doesn't impact the ability to download files from S3 URLs which have plus signs in their file name<br />
** Using urlencoding_mode=fixbucket does not work. Yum will download the file w/o URL encoding (e.g. with plus chars in the file name), and S3 won't return that file because it doesn't exist.<br />
* The MD5 checks don't happen at all for files uploaded via multipart, which seems to affect larger files. This defeats the purpose of MD5 checking. But, we can't disable MD5 checking for all files, because repomd.xml often changes content but doesn't change file size. So, we need MD5 checking only for some files.<br />
* turns out we need MD5 checking for package re-signing too. I guess we're stuck with using MD5 checking.<br />
** We could put additional custom metadata (e.g. RPM package field data) into S3 if we wanted to. That would make s3cmd more tailored to our use case.<br />
** It does store mtime/ctime values in the metadata. Need to add code to check those.<br />
* upload of initial bucket for EPEL took real 651m57.042s, /pub/fedora took real 892m52.286s.<br />
* subsequent syncs failed because of the above element error, but took 12m and 21m respectively (w/o transferring any changes due to the error)<br />
* MirrorManager's report_mirror program needs to be run after the sync, because this will be a private mirror. But, it also blindly does os.walk(), without a concept of excludes. Solutions are to either make a private copy of the whole content (ugh!), or add --exclude-from=<file> handling to report_mirror. Matt did the latter.<br />
* no hardlinks. Total /pub/epel and /pub/fedora trees take ~77GB. Bug filed https://github.com/s3tools/s3cmd/issues/29<br />
** If we use S3->S3 copy within one region, we can get 17-22MB/sec out of the copy, instead of ~700KB/sec doing uploads or S3->S3 inter-region copying. So let's get hardlinks working!!<br />
* no softlinks. This could pose a problem for EPEL consumers, where the version strings look like '4AS' which we've pointed at '4'. May be able to work around it with MM redirects.<br />
* No --delete-after option, deletes occur before new content is uploaded, which puts the repository into an inconsistent state during the upload. Matt has an upstream pull request to fix this: https://github.com/s3tools/s3cmd/pull/30</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Archive:Infrastructure/Mirroring/Amazon&diff=546682Archive:Infrastructure/Mirroring/Amazon2019-06-30T12:14:52Z<p>Puiterwijk: </p>
<hr />
<div>{{warning|This page was a draft proposal from a long time ago. This is kept for posterity, but users should not use the URLs in this page. Please use mirrorlist for all repo configurations.}} <br />
<br />
<br />
Initial thoughts by Matt Domsch<br />
<br />
* Use Reduced Redundancy Storage. All the content will be replicated easily.<br />
* Use s3cmd sync to keep content in buckets in sync<br />
* see exclude list below<br />
* Use bucket policies to limit access to each region (if needed; not implemented yet)<br />
* Need list of IP addresses for each region to populate MM. Would be nice if we could get that programmatically.<br />
** https://forums.aws.amazon.com/ann.jspa?annID=1453<br />
** This moves around, so start there, then go to Forums, Elastic Compute Cloud, and look for the sticky thread.<br />
* syncing from bapp01 at present because it has r/o access to the trees<br />
<br />
* bucket names s3-mirror-<region>.fedoraproject.org allow for CNAME s3-mirror.fedoraproject.org to s3.amazon.com in our DNS<br />
{|<br />
| Region || Region Server || Bucket Name || CNAME<br />
|-<br />
| US Standard || s3-website-us-east-1.amazonaws.com || s3-mirror-us-east-1.fedoraproject.org || s3-mirror-us-east-1.fedoraproject.org CNAME s3-mirror-us-east-1.fedoraproject.org.s3-website-us-east-1.amazonaws.com<br />
|-<br />
| US West (Oregon) Region || s3-website-us-west-2.amazonaws.com || s3-mirror-us-west-2.fedoraproject.org<br />
|-<br />
| US West (Northern California) Region || s3-website-us-west-1.amazonaws.com || s3-mirror-us-west-1.fedoraproject.org<br />
|-<br />
| EU (Ireland) Region || s3-website-eu-west-1.amazonaws.com<br />
|-<br />
| Asia Pacific (Singapore) Region || s3-website-ap-southeast-1.amazonaws.com<br />
|-<br />
| Asia Pacific (Tokyo) Region || s3-website-ap-northeast-1.amazonaws.com<br />
|-<br />
| South America (Sao Paulo) Region || s3-website-sa-east-1.amazonaws.com<br />
|}<br />
<br />
<br />
** http://docs.amazonwebservices.com/AmazonS3/latest/dev/WebsiteEndpoints.html<br />
<br />
<br />
<br />
Torrents:<br />
* if we upload ISOs, we get .torrent links "for free".<br />
* no tracker stats :-(<br />
* Can't group multiple files together into a single torrent<br />
* we're paying for outbound bandwidth<br />
* bucket policies keeping traffic in a single region means we need separate buckets for torrent content<br />
<br />
<br />
<br />
Costs:<br />
* none for all uploads<br />
* none for intra-region requests<br />
* 0.093/GB/month for data, ~218GB = $20/month/region. 7 Regions, but start in US East 1 only for now.<br />
* a good number of PUT and LIST requests due to mirroring several times a day. Could be another $20/month just for those.<br />
* no way guess number of GET requests. $40 assumes 10M requests, while $30/month assumes 1M requests.<br />
Total: ~$280/month, or $3360/yr<br />
<br />
Open questions:<br />
* do we sync to one region, then COPY to others? If so, what tool? That'll cost $ for bandwidth.<br />
<br />
Proposed Excludes:<br />
<pre><br />
source/<br />
SRPMS/<br />
debug/<br />
beta/<br />
ppc/<br />
ppc64/<br />
repoview/<br />
Fedora/<br />
Live/<br />
isolinux/<br />
images/<br />
EFI/<br />
drpms/<br />
core/<br />
extras/<br />
LiveOS/<br />
updates/8<br />
updates/9<br />
updates/10<br />
updates/11<br />
updates/12<br />
updates/13<br />
updates/14<br />
updates/testing/8<br />
updates/testing/9<br />
updates/testing/10<br />
updates/testing/11<br />
updates/testing/12<br />
updates/testing/13<br />
updates/testing/14<br />
releases/test/<br />
</pre><br />
<br />
<br />
== Problems Encountered ==<br />
<br />
* s3cmd sync processes excludes after walking the whole local directory tree with os.walk(). This means it recurses over .snapshot/ and all the directories we want to exclude, increasing processing time by 20x (>700k files vs ~35k files we'll actually upload). Matt has an upstream pull request to fix this. https://github.com/s3tools/s3cmd/pull/27<br />
* On subsequent syncs, got this error from the /pub/epel tree:<br />
<pre><br />
ERROR: no element found: line 1, column 0<br />
ERROR: Parameter problem: Bucket contains invalid filenames. Please run: s3cmd fixbucket s3://your-bucket/<br />
</pre><br />
** This is caused by file names that have plus characters in their name.<br />
** Upstream bug: https://github.com/s3tools/s3cmd/issues/28<br />
** this doesn't impact the ability to download files from S3 URLs which have plus signs in their file name<br />
** Using urlencoding_mode=fixbucket does not work. Yum will download the file w/o URL encoding (e.g. with plus chars in the file name), and S3 won't return that file because it doesn't exist.<br />
* The MD5 checks don't happen at all for files uploaded via multipart, which seems to affect larger files. This defeats the purpose of MD5 checking. But, we can't disable MD5 checking for all files, because repomd.xml often changes content but doesn't change file size. So, we need MD5 checking only for some files.<br />
* turns out we need MD5 checking for package re-signing too. I guess we're stuck with using MD5 checking.<br />
** We could put additional custom metadata (e.g. RPM package field data) into S3 if we wanted to. That would make s3cmd more tailored to our use case.<br />
** It does store mtime/ctime values in the metadata. Need to add code to check those.<br />
* upload of initial bucket for EPEL took real 651m57.042s, /pub/fedora took real 892m52.286s.<br />
* subsequent syncs failed because of the above element error, but took 12m and 21m respectively (w/o transferring any changes due to the error)<br />
* MirrorManager's report_mirror program needs to be run after the sync, because this will be a private mirror. But, it also blindly does os.walk(), without a concept of excludes. Solutions are to either make a private copy of the whole content (ugh!), or add --exclude-from=<file> handling to report_mirror. Matt did the latter.<br />
* no hardlinks. Total /pub/epel and /pub/fedora trees take ~77GB. Bug filed https://github.com/s3tools/s3cmd/issues/29<br />
** If we use S3->S3 copy within one region, we can get 17-22MB/sec out of the copy, instead of ~700KB/sec doing uploads or S3->S3 inter-region copying. So let's get hardlinks working!!<br />
* no softlinks. This could pose a problem for EPEL consumers, where the version strings look like '4AS' which we've pointed at '4'. May be able to work around it with MM redirects.<br />
* No --delete-after option, deletes occur before new content is uploaded, which puts the repository into an inconsistent state during the upload. Matt has an upstream pull request to fix this: https://github.com/s3tools/s3cmd/pull/30</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Archive:Using_the_package_database&diff=539392Archive:Using the package database2019-04-02T16:41:12Z<p>Puiterwijk: pkgdb is retired</p>
<hr />
<div>{{deprecated|Package Database has been retired and replaced by Pagure.}}<br />
<br />
<br />
= Using the Fedora Package Database =<br />
<br />
The Package Database is the place where we track ownership of packages and permissions on who is allowed to commit to a package.<br />
<br />
<br />
<br />
== Accessing the Interface ==<br />
<br />
=== Where is the Package Database? ===<br />
The packagedb is located at https://admin.fedoraproject.org/pkgdb/<br />
<br />
=== Where should I go from there? ===<br />
The links on the left side of the main page give you access to the major views of the information in the Package Database.<br />
<br />
* The [https://admin.fedoraproject.org/pkgdb/collections/ View Collections] and [https://admin.fedoraproject.org/pkgdb/packages/ View Packages] links allow you to browse through a list of packages, looking for information on them.<br />
* [https://admin.fedoraproject.org/pkgdb/orphaned/ Orphan Packages] displays a list of packages which are orphaned in one or more active branches.<br />
* [https://fedorahosted.org/pkgdb2/ Project Page] and [https://fedorahosted.org/pkgdb2/newticket Report Bugs] Take you to the Package Database's project page for getting involved with development of the PkgDB2 code.<br />
<br />
=== What's the fastest way to find a package? ===<br />
To directly access a package you're interested in simply replace PACKAGENAME in the following URL with the name of the package:<br />
<pre><br />
https://admin.fedoraproject.org/pkgdb/package/PACKAGENAME<br />
</pre><br />
<br />
There is also an [http://en.wikipedia.org/wiki/OpenSearch OpenSearch] extension offering to search packages or packagers directly in your browser.<br />
<br />
=== Logging in ===<br />
The upper right hand corner of the Package Database has a brief message that says <code>Login</code>. When you click on Login, you are redirected to the Fedora OpenID page where you will enter your username and password. Once these are entered, you will be able to make changes in the Package Database.<br />
<br />
== Signing up for packages ==<br />
<br />
=== How do I sign up for a package? ===<br />
Navigate to the package's page in the Package Database. If you have not logged in, go ahead and do that now. At this point you should be back at the package's page and either click on the button <code>Request Commit Access</code> to request access on all branches or use the button <code>Request Commit ACLs</code> to specify which branch you would like to have access for. Below in the page you can ask for <code>watchcommits</code> and <code>watchbugzilla</code> access via the button <code>Watch this package</code><br />
<br />
* watchcommits and watchbugzilla are for receiving email notifications for package changes.<br />
* commit is for access to commit to the SCM.<br />
* approveacls is to be allowed to approveacls just like the package owner.<br />
<br />
=== I'm the package maintainer, how do I give someone commit access to my package? ===<br />
Go to the page of the package and click on <code>Manage the committers</code>. There you have a grey button to <code>Add someone</code> and give him/her the ACLs you want on one or more branches.<br />
<br />
=== How do I find orphaned packages that I can take over? ===<br />
This main source of information is:<br />
https://admin.fedoraproject.org/pkgdb/orphaned/<br />
<br />
But information is currently also present in the wiki:<br />
http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages<br />
http://fedoraproject.org/wiki/PackageMaintainers/RetiredPackages<br />
<br />
If you'd like to work on migrating this information into the PackageDB, please see [https://fedorahosted.org/packagedb/ticket/54 this ticket] .<br />
<br />
== Working with your packages ==<br />
<br />
=== How can I find my packages? ===<br />
<br />
The easiest way to find the packages you work with is to search your name in the list of packagers, or simply to log-in and click on your name at the top right corner of the page.<br />
<br />
This view shows you every package for which you have an acl in a non-EOL branch. (So a package for which you only have watchbugzilla in EPEL7 will show up. A package for which you are the owner in Fedora Core 3 will not.)<br />
<br />
==== How can I only list packages I'm comaintainer of? ====<br />
<br />
The page makes the distinction between package where you have the commit ACL and packages where you are the point of contact and finally packages where you have one of the watch* ACLs.<br />
<br />
==== How can I list packages which I was interested in on an EOL branch? ====<br />
<br />
Add <code>eol=True</code> to the end of the url.<br />
<br />
Here's an example that lists packages that pingou was the point of contact including EOL branches:<br />
<pre><br />
https://admin.fedoraproject.org/pkgdb/packager/pingou/?eol=True<br />
</pre><br />
<br />
'''This is implemented in 1.9'''<br />
<br />
=== How can I add a new package or add a package to a new branch? ===<br />
These actions require manual work to be done by an administrator so follow the steps in [[package SCM admin requests]] .<br />
<br />
Eventually we hope to make these steps more automated with a form to request a new branch and another form to request a new package. If you'd like to work on this, please see [https://fedorahosted.org/packagedb/ticket/18 this ticket]<br />
<br />
== PackageDB API ==<br />
Some of the PackageDB data can be accessed by scripts as JSON or plain text data. This data is made available to make scripting easier. The whole API is documented at: https://admin.fedoraproject.org/pkgdb/api/<br />
<br />
The best way to retrieve this data is by using the client library present in packagedb-cli. <code>yum install packagedb-cli</code> then setup a pkgdb client object and call methods on it like this:<br />
<br />
<pre><br />
from pkgdb2client import PkgDB<br />
# username and password are optional -- in general, only methods that<br />
# modify data will need them to have been specified<br />
pkgdb = PkgDB(username='me', password='XXXX')<br />
pkgdb.get_packages('gu*')<br />
</pre><br />
<br />
Documentation for the pkgdb2client module is in the sources: https://github.com/fedora-infra/packagedb-cli/blob/master/pkgdb2client/cli.py<br />
<br />
If, for some reason, you must retrieve the information without the help of the client library, you can use the urls directly like this. For instance, Bugzilla Acls can be retrieved in the following ways:<br />
<br />
<pre><br />
HTML:<br />
https://admin.fedoraproject.org/pkgdb/api/bugzilla<br />
<br />
Plain Text:<br />
https://admin.fedoraproject.org/pkgdb/api/bugzilla?format=text<br />
<br />
JSON:<br />
https://admin.fedoraproject.org/pkgdb/api/bugzilla?format=json<br />
</pre><br />
<br />
Each method exposed to the user has a different rating for stability depending on several criteria:<br />
* Stable: The format of data, URL location, and query parameters are not expected to change. If changes occur, they will be announced and deprecated ahead of time.<br />
* Proven: The data format is stable. URL location and query parameters may change but a method of retrieving the data in its current form will remain available. API with this status will have notes to explain just how much it can be depended on.<br />
* In Flux: The data being exposed by this method will continue but the URL location, format, or query parameters to retrieve it may change.<br />
* Unstable: Anything about this method could change including disappearing entirely.<br />
<br />
{{admon/warning||Note that using python-fedora remains the best method of accessing this data. We can add compatibility shims to that even when the server code changes. The server code is undergoing some redesigns that may make things change -- in particular, we are moving away from returning representations of the database tables directly and making changes to the database schema. These may cause changes to even the Proven API.}}<br />
<br />
=== Bugzilla Acls ===<br />
<br />
{| border="1"<br />
|-<br />
|Base URL||https://admin.fedoraproject.org/pkgdb/api/bugzilla<br />
|-<br />
|Plain Format||Stable<br />
|-<br />
|JSON Format||Stable<br />
|}<br />
The bugzilla acl page returns information about package ownership, summary information, and initialcclist that bugzilla needs to know. At present (and unless a change occurs in bugzilla that would obviate this), the information is based on the information for the latest release of the product. At the moment Nov, 19, 2007, those are Fedora Devel, Fedora EPEL 5, and Fedora OLPC 2.<br />
<br />
=== VCS Acls ===<br />
<br />
{| border="1"<br />
|-<br />
|Base Url||https://admin.fedoraproject.org/pkgdb/api/vcs<br />
|-<br />
|Plain Format||Stable<br />
|-<br />
|JSON Format||Stable<br />
|}<br />
The VCS Acls page returns information about who can commit to a package.<br />
<br />
=== Critpath packages ===<br />
<br />
{| border="1"<br />
|-<br />
|Base Url||https://admin.fedoraproject.org/pkgdb/api/critpath<br />
|-<br />
|Plain Format||Stable<br />
|-<br />
|JSON Format||Stable<br />
|}<br />
The critpath page returns the list of package marked as being part of the critical path.<br />
<br />
=== Package Information ===<br />
{| border="1"<br />
|-<br />
|Base Url||https://admin.fedoraproject.org/pkgdb/api/package/PKGNAME<br />
|-<br />
|JSON Format||Stable<br />
|}<br />
<br />
=== User Package List ===<br />
{| border="1"<br />
|-<br />
|Base Url||https://admin.fedoraproject.org/pkgdb/api/packager/USERNAME<br />
|-<br />
|JSON Format||Stable<br />
|}<br />
Returns a list of packages belonging to the user with the ability to filter on certain acls via query params. The query params may be added to in the future and the URL location may change as well.<br />
<br />
<br />
[[Category:Package Maintainers]]</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Infrastructure/Kerberos&diff=527453Infrastructure/Kerberos2018-10-20T09:08:19Z<p>Puiterwijk: Remove note fixed by GSSAPI</p>
<hr />
<div>= Infrastructure kerberos authentication =<br />
<br />
== Background ==<br />
<br />
Starting in November 2016, Fedora Infrastructure began to use kerberos authentication for some services, starting with koji (the Fedora build system). On December 12th 2016, the koji buildsystem will be switched to only allow kerberos authentication, and disallow the old ssl cert authentication. <br />
<br />
== Supported Services ==<br />
<br />
* koji<br />
<br />
* All Fedora Infrastructure ipsilon using applications via GSSAPI<br />
<br />
== Technical Details ==<br />
<br />
Fedora Infrastructure still uses the Fedora Account System (FAS), but now it syncs some account information to a pair of FreeIPA servers. Those servers are made available via a web proxy to Fedora contributors. Also, via the [https://pagure.io/ipsilon ipsilon] identity management server and GSSAPI we are able to use Kerberos tickets to authenticate users to any services that use ipsilon.<br />
<br />
== How to use kerberos auth with Fedora Infrastructure ==<br />
<br />
=== Command line ===<br />
<br />
* Store your FAS username (all lower case) in <code>~/.fedora.upn</code> (This is not actually needed for Kerberos but for other tools that used the Fedora client certificate to determine the FAS username)<br />
* <code>kinit <yourfasloginname>@FEDORAPROJECT.ORG</code><br />
** (Yes, upper-case FEDORAPROJECT.ORG — that's the convention for Kerberos.)<br />
** You need to do this regularly whenever fedpkg or koji authentication fail. There is no support for these tools to prompt you automatically when the ticket expired.<br />
** Install the <code>krb5-workstation</code> package (<code>sudo dnf install krb5-workstation</code>) if you do not have <code>kinit</code> command available.<br />
** You can set <code>default_realm = FEDORAPROJECT.ORG</code> in <code>/etc/krb5.conf</code> to avoid each typing <code>@FEDORAPROJECT.ORG</code>.<br />
* Enter your FAS password<br />
* You should now be able to authenticate to supported services (koji and lookaside upload)<br />
<br />
* Tickets are valid for 24 hours and can be renewed for 1 week. You can renew a existing ticket with <code>kinit -R <yourfasloginname>@FEDORAPROJECT.ORG</code><br />
<br />
=== GUI (gnome/workstation) ===<br />
<br />
* Open settings -> Online Accounts -> Click on the + to add an account -> Click on "Other" at the end of the list -> Click on "Enterprise login (kerberos)"<br />
* Enter your FAS name @FEDORAPROJECT.ORG for the principal, e.g. fas@FEDORAPROJECT.ORG.<br />
* Enter your password when prompted. <br />
<br />
=== Firefox ===<br />
<br />
If you have Firefox 49 or higher and not tweaked any special configuration, you are done.<br />
If you have a lower version or want to check:<br />
* Go to about:config<br />
* Click the "I accept the risk" button<br />
* Search for "network.negotiate-auth.trusted-uris"<br />
* Double-click this option if it's not set to "https://", and set it to "https://"<br />
<br />
=== Chromium/Chrome ===<br />
<br />
For Chrome/Chromium, you need to create a policy file.<br />
<br />
* For Chromium, the directory to put this in is /etc/chromium/policies/managed/ .<br />
* For Chrome, the directory is /etc/opt/chrome/policies/managed/ (you might have to create this yourself).<br />
<br />
In that, create a file (e.g. fedora_kerberos.json), with contents:<br />
<br />
<pre><br />
{<br />
"AuthServerWhitelist": "*.fedoraproject.org",<br />
"AuthNegotiateDelegateWhitelist": "*.fedoraproject.org"<br />
}<br />
</pre><br />
<br />
<br />
For Mac Chrome/Chromium, you need to enter command<br />
<br />
<pre><br />
<br />
sudo defaults write /Library/Preferences/com.google.Chrome.plist AuthServerWhitelist '.fedoraproject.org'<br />
sudo defaults write /Library/Preferences/com.google.Chrome.plist AuthNegotiateDelegateWhitelist '.fedoraproject.org'<br />
<br />
</pre><br />
<br />
== Questions and Answers ==<br />
<br />
'''Question:''' Is there any particular format for username / domain I need to use?<br />
<br />
'''Answer:''' Yes. Your username should be all lower case, and the domain name should be all UPPER CASE. ie, <code>username@FEDORAPROJECT.ORG</code><br />
<br />
'''Question:''' How can I see how long my ticket(s) are valid for?<br />
<br />
'''Answer:''' use <code>klist -A</code><br />
<br />
'''Question:''' I don't seem to be logged into the koji web interface after this, why not?<br />
<br />
'''Answer:''' Logging into the koji web interface doesn't really get you much of anything, but you can get a valid ticket and then go to https://koji.fedoraproject.org/koji/login in your browser and you will be logged in.<br />
<br />
'''Question:''' When I run kinit I get: Client 'yourname@FEDORAPROJECT.ORG' not found in Kerberos database while getting initial credentials<br />
<br />
'''Answer:''' Login to [https://admin.fedoraproject.org/accounts FAS] and then retry. Your information needs to be synced from FAS to the IPA server. Logging into FAS does so.<br />
<br />
'''Question:''' I did that (logged into FAS) in the last answer, and it didn't help, I still get the same error message. What's going on?<br />
<br />
'''Answer:''' For some small number of users there may be some issue with syncing information from fas->ipa. If this happens to you, please file an infrastructure ticket or talk with us on {{fpchat|#fedora-admin}} and we can manually fix things. <br />
<br />
'''Question:''' It's not working for me, how can I gather debugging information?<br />
<br />
'''Answer:''' Run the command with <code>KRB5_TRACE=/dev/stdout</code> in front of it and it should print a lot of debugging information. <br />
<br />
'''Question:''' koji and/or fedpkg don't seem to be working for me.<br />
<br />
'''Answer:''' Make sure you have upgraded to the versions listed above and also make sure you fold changes from <code>/etc/koji.conf.rpmnew</code> (if you ever modified your <code>/etc/koji.conf</code>) and your <code>~/.koji/config</code>. Note that in normal operation you can just use the stock <code>/etc/koji.conf</code> from the koji package and there is no need for a <code>~/.koji/config</code>. If it still doesn't work also check <code>/etc/rpkg/fedpkg.conf.rpmnew</code> and update your old config if it exists.<br />
<br />
'''Question:''' Where should I report problems or get help? <br />
<br />
'''Answer:''' {{fpchat|#fedora-admin}} on IRC or [https://pagure.io/fedora-infrastructure/issues file a fedora-infrastructure ticket] and we will try and assist you!<br />
<br />
'''Question:''' "kinit: Cannot find KDC for realm "FEDORAPROJECT.ORG" while getting initial credentials"?<br />
<br />
'''Answer:''' Try adding "includedir /etc/krb5.conf.d/" as the top line in the /etc/krb5.conf file<br />
<br />
'''Question:''' After entering my password I get: Password incorrect while getting initial credentials<br />
<br />
'''Answer:''' Please make sure you enter your correct password. If you are sure you entered the correct password, but it doesn't work, please visit the [https://admin.fedoraproject.org/accounts/ Fedora Account System] and log in and change your password. '''NOTE: Resetting your password does *NOT* update the Kerberos password.''' If you forgot your password, first use the password reset feature and then log in again to FAS and use the change password link.<br />
<br />
'''Question:''' Using Koji, I get an error "ImportError: Please install python-krbV to use kerberos"<br />
<br />
'''Answer:''' Please make sure that in /etc/krb5.conf, under [libdefaults], the option "rdns = false" is set. Note that this might break some non-Fedora krb5 services, but this is required to make GSSAPI work against Fedora services.<br />
<br />
== Debugging problems ==<br />
<br />
There is [https://github.com/puiterwijk/KrbDebug/blob/master/KrbDebug a script that can check your configuration] and tell you if there is any common problem. Just clone the repository and run the script.<br />
<br />
<pre><br />
$ git clone https://github.com/puiterwijk/KrbDebug.git<br />
$ cd KrbDebug/<br />
$ ./KrbDebug<br />
</pre><br />
<br />
== Extra info for Infrastructure people ==<br />
<br />
To access nagios, you need to use Kerberos as well.<br />
This will require you to change /etc/krb5.conf, and under [libdefaults] add or set "rdns = false" and "dns_canonicalize_hostname = false".</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Infrastructure/Kerberos&diff=527452Infrastructure/Kerberos2018-10-20T09:04:58Z<p>Puiterwijk: Typofix</p>
<hr />
<div>= Infrastructure kerberos authentication =<br />
<br />
== Background ==<br />
<br />
Starting in November 2016, Fedora Infrastructure began to use kerberos authentication for some services, starting with koji (the Fedora build system). On December 12th 2016, the koji buildsystem will be switched to only allow kerberos authentication, and disallow the old ssl cert authentication. <br />
<br />
== Supported Services ==<br />
<br />
* koji<br />
<br />
* All Fedora Infrastructure ipsilon using applications via GSSAPI<br />
<br />
== Technical Details ==<br />
<br />
Fedora Infrastructure still uses the Fedora Account System (FAS), but now it syncs some account information to a pair of FreeIPA servers. Those servers are made available via a web proxy to Fedora contributors. Also, via the [https://pagure.io/ipsilon ipsilon] identity management server and GSSAPI we are able to use Kerberos tickets to authenticate users to any services that use ipsilon.<br />
<br />
== How to use kerberos auth with Fedora Infrastructure ==<br />
<br />
=== Command line ===<br />
<br />
* Store your FAS username (all lower case) in <code>~/.fedora.upn</code> (This is not actually needed for Kerberos but for other tools that used the Fedora client certificate to determine the FAS username)<br />
* <code>kinit <yourfasloginname>@FEDORAPROJECT.ORG</code><br />
** (Yes, upper-case FEDORAPROJECT.ORG — that's the convention for Kerberos.)<br />
** You need to do this regularly whenever fedpkg or koji authentication fail. There is no support for these tools to prompt you automatically when the ticket expired.<br />
** Install the <code>krb5-workstation</code> package (<code>sudo dnf install krb5-workstation</code>) if you do not have <code>kinit</code> command available.<br />
** You can set <code>default_realm = FEDORAPROJECT.ORG</code> in <code>/etc/krb5.conf</code> to avoid each typing <code>@FEDORAPROJECT.ORG</code>.<br />
* Enter your FAS password<br />
* You should now be able to authenticate to supported services (koji and lookaside upload)<br />
<br />
* Tickets are valid for 24 hours and can be renewed for 1 week. You can renew a existing ticket with <code>kinit -R <yourfasloginname>@FEDORAPROJECT.ORG</code><br />
<br />
=== GUI (gnome/workstation) ===<br />
<br />
* Open settings -> Online Accounts -> Click on the + to add an account -> Click on "Other" at the end of the list -> Click on "Enterprise login (kerberos)"<br />
* Enter your FAS name @FEDORAPROJECT.ORG for the principal, e.g. fas@FEDORAPROJECT.ORG.<br />
* Enter your password when prompted. <br />
<br />
=== Firefox ===<br />
<br />
If you have Firefox 49 or higher and not tweaked any special configuration, you are done.<br />
If you have a lower version or want to check:<br />
* Go to about:config<br />
* Click the "I accept the risk" button<br />
* Search for "network.negotiate-auth.trusted-uris"<br />
* Double-click this option if it's not set to "https://", and set it to "https://"<br />
<br />
=== Chromium/Chrome ===<br />
<br />
For Chrome/Chromium, you need to create a policy file.<br />
<br />
* For Chromium, the directory to put this in is /etc/chromium/policies/managed/ .<br />
* For Chrome, the directory is /etc/opt/chrome/policies/managed/ (you might have to create this yourself).<br />
<br />
In that, create a file (e.g. fedora_kerberos.json), with contents:<br />
<br />
<pre><br />
{<br />
"AuthServerWhitelist": "*.fedoraproject.org",<br />
"AuthNegotiateDelegateWhitelist": "*.fedoraproject.org"<br />
}<br />
</pre><br />
<br />
<br />
For Mac Chrome/Chromium, you need to enter command<br />
<br />
<pre><br />
<br />
sudo defaults write /Library/Preferences/com.google.Chrome.plist AuthServerWhitelist '.fedoraproject.org'<br />
sudo defaults write /Library/Preferences/com.google.Chrome.plist AuthNegotiateDelegateWhitelist '.fedoraproject.org'<br />
<br />
</pre><br />
<br />
== Questions and Answers ==<br />
<br />
'''Question:''' Is there any particular format for username / domain I need to use?<br />
<br />
'''Answer:''' Yes. Your username should be all lower case, and the domain name should be all UPPER CASE. ie, <code>username@FEDORAPROJECT.ORG</code><br />
<br />
'''Question:''' I have 2 (or more) domains I login to with kerberos and koji only seems to work when it's the last one I add, whats going on? (The error it will show is "Kerberos authentication failed: Server not found in Kerberos database (-1765328377)")<br />
<br />
'''Answer:''' koji currently requires this, but there's a patch coming to fix it. In the mean time you can use <code>kswitch</code> to switch which is primary. <br />
<br />
'''Question:''' How can I see how long my ticket(s) are valid for?<br />
<br />
'''Answer:''' use <code>klist -A</code><br />
<br />
'''Question:''' I don't seem to be logged into the koji web interface after this, why not?<br />
<br />
'''Answer:''' Logging into the koji web interface doesn't really get you much of anything, but you can get a valid ticket and then go to https://koji.fedoraproject.org/koji/login in your browser and you will be logged in.<br />
<br />
'''Question:''' When I run kinit I get: Client 'yourname@FEDORAPROJECT.ORG' not found in Kerberos database while getting initial credentials<br />
<br />
'''Answer:''' Login to [https://admin.fedoraproject.org/accounts FAS] and then retry. Your information needs to be synced from FAS to the IPA server. Logging into FAS does so.<br />
<br />
'''Question:''' I did that (logged into FAS) in the last answer, and it didn't help, I still get the same error message. What's going on?<br />
<br />
'''Answer:''' For some small number of users there may be some issue with syncing information from fas->ipa. If this happens to you, please file an infrastructure ticket or talk with us on {{fpchat|#fedora-admin}} and we can manually fix things. <br />
<br />
'''Question:''' It's not working for me, how can I gather debugging information?<br />
<br />
'''Answer:''' Run the command with <code>KRB5_TRACE=/dev/stdout</code> in front of it and it should print a lot of debugging information. <br />
<br />
'''Question:''' koji and/or fedpkg don't seem to be working for me.<br />
<br />
'''Answer:''' Make sure you have upgraded to the versions listed above and also make sure you fold changes from <code>/etc/koji.conf.rpmnew</code> (if you ever modified your <code>/etc/koji.conf</code>) and your <code>~/.koji/config</code>. Note that in normal operation you can just use the stock <code>/etc/koji.conf</code> from the koji package and there is no need for a <code>~/.koji/config</code>. If it still doesn't work also check <code>/etc/rpkg/fedpkg.conf.rpmnew</code> and update your old config if it exists.<br />
<br />
'''Question:''' Where should I report problems or get help? <br />
<br />
'''Answer:''' {{fpchat|#fedora-admin}} on IRC or [https://pagure.io/fedora-infrastructure/issues file a fedora-infrastructure ticket] and we will try and assist you!<br />
<br />
'''Question:''' "kinit: Cannot find KDC for realm "FEDORAPROJECT.ORG" while getting initial credentials"?<br />
<br />
'''Answer:''' Try adding "includedir /etc/krb5.conf.d/" as the top line in the /etc/krb5.conf file<br />
<br />
'''Question:''' After entering my password I get: Password incorrect while getting initial credentials<br />
<br />
'''Answer:''' Please make sure you enter your correct password. If you are sure you entered the correct password, but it doesn't work, please visit the [https://admin.fedoraproject.org/accounts/ Fedora Account System] and log in and change your password. '''NOTE: Resetting your password does *NOT* update the Kerberos password.''' If you forgot your password, first use the password reset feature and then log in again to FAS and use the change password link.<br />
<br />
'''Question:''' Using Koji, I get an error "ImportError: Please install python-krbV to use kerberos"<br />
<br />
'''Answer:''' Please make sure that in /etc/krb5.conf, under [libdefaults], the option "rdns = false" is set. Note that this might break some non-Fedora krb5 services, but this is required to make GSSAPI work against Fedora services.<br />
<br />
== Debugging problems ==<br />
<br />
There is [https://github.com/puiterwijk/KrbDebug/blob/master/KrbDebug a script that can check your configuration] and tell you if there is any common problem. Just clone the repository and run the script.<br />
<br />
<pre><br />
$ git clone https://github.com/puiterwijk/KrbDebug.git<br />
$ cd KrbDebug/<br />
$ ./KrbDebug<br />
</pre><br />
<br />
== Extra info for Infrastructure people ==<br />
<br />
To access nagios, you need to use Kerberos as well.<br />
This will require you to change /etc/krb5.conf, and under [libdefaults] add or set "rdns = false" and "dns_canonicalize_hostname = false".</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Infrastructure/HTTPS-commits&diff=526471Infrastructure/HTTPS-commits2018-10-05T20:50:15Z<p>Puiterwijk: </p>
<hr />
<div>= HTTPS commits to src.fedoraproject.org =<br />
<br />
== Background ==<br />
<br />
In the past, pkgs.fedoraproject.org was the host that maintainers used to upload package sources via https and push commits via ssh. All such commits via ssh required the user to be in the 'packager' group, because the host created actual accounts for each packager, then restricted them to commits. If a user was not in that group, they wouldn't be known to the acls and would be denied. <br />
<br />
When we moved to src.fedoraproject.org with a pagure instance in front of it, this limitation was still in place, leading to users who aren't in the packagers group being able to fork packages, but being unable to push to their forks. <br />
<br />
This limitation is now removed by using https pushes, which are available for all users who have permissions to commit to packages/modules/containers/tests or forks thereof. <br />
<br />
== How it works ==<br />
<br />
fedpkg (starting with version 1.34) has the ability to fetch a OIDC token from src.fedoraproject.org and then use that token to push commits over https. <br />
You also need to make sure and have python-openidc-client => 0.6.0 installed)<br />
<br />
You will need to do your git clone with -a (anonymous) for now, and will need to using a graphical session (so your browser can be used to get the token you need). <br />
<br />
== Future plans ==<br />
<br />
Slowly over time we plan to transition all users to https pushing for commits and retire the ssh service. There will be a lot of notice for this and it will only happen after https pushing is well established and working. <br />
<br />
== FAQ ==<br />
<br />
Q: On push, git asks for a username and password, what do I enter there?<br />
<br />
A: This means you cloned with an old version of fedpkg. Do a fedpkg push (instead of git push) once after upgrading to fedpkg 1.34 or higher. Under no circumstances should you enter your FAS password in the CLI.<br />
<br />
Q: I want to use normal 'git push', can I? <br />
<br />
A: Yes, if you cloned it with a recent enough fedpkg. If it asks for your password, rerun the fedpkg clone command, or run "fedpkg push" for now. <br />
<br />
Q: Can I do a push on a headless machine? <br />
<br />
A: Not yet. Currently you need a graphical session with a browser (firefox, chrome, etc). This will get fixed down the road. <br />
<br />
Q: Can I still push via ssh?<br />
<br />
A: If you are in the packager group you can still push via ssh for now. In time, we are planning to deprecate this.<br />
<br />
Q: I get the message "Token was renewed. Please rerun command" when trying to push.<br />
<br />
A: This means the tool has realized your token has expired and renewed it. Just press arrow-up enter and it should work.</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Infrastructure/HTTPS-commits&diff=526408Infrastructure/HTTPS-commits2018-10-02T20:39:37Z<p>Puiterwijk: </p>
<hr />
<div>= HTTPS commits to src.fedoraproject.org =<br />
<br />
== Background ==<br />
<br />
In the past, pkgs.fedoraproject.org was the host that maintainers used to upload package sources via https and push commits via ssh. All such commits via ssh required the user to be in the 'packager' group, because the host created actual accounts for each packager, then restricted them to commits. If a user was not in that group, they wouldn't be known to the acls and would be denied. <br />
<br />
When we moved to src.fedoraproject.org with a pagure instance in front of it, this limitation was still in place, leading to users who aren't in the packagers group being able to fork packages, but being unable to push to their forks. <br />
<br />
This limitation is now removed by using https pushes, which are available for all users who have permissions to commit to packages/modules/containers/tests or forks thereof. <br />
<br />
== How it works ==<br />
<br />
fedpkg (starting with version 1.34) has the ability to fetch a OIDC token from src.fedoraproject.org and then use that token to push commits over https. <br />
You also need to make sure and have python-openidc-client => 0.6.0 installed)<br />
<br />
You will need to do your git clone with -a (anonymous) for now, and will need to using a graphical session (so your browser can be used to get the token you need). <br />
<br />
== Future plans ==<br />
<br />
Slowly over time we plan to transition all users to https pushing for commits and retire the ssh service. There will be a lot of notice for this and it will only happen after https pushing is well established and working. <br />
<br />
== FAQ ==<br />
<br />
Q: On push, git asks for a username and password, what do I enter there?<br />
<br />
A: This means you cloned with an old version of fedpkg. Do a fedpkg push (instead of git push) once after upgrading to fedpkg 1.34 or higher. Under no circumstances should you enter your FAS password in the CLI.<br />
<br />
Q: I want to use normal 'git push', can I? <br />
<br />
A: Yes, if you cloned it with a recent enough fedpkg. If it asks for your password, rerun the fedpkg clone command, or run "fedpkg push" for now. <br />
<br />
Q: Can I do a push on a headless machine? <br />
<br />
A: Not yet. Currently you need a graphical session with a browser (firefox, chrome, etc). This will get fixed down the road. <br />
<br />
Q: Can I still push via ssh?<br />
<br />
A: If you are in the packager group you can still push via ssh for now. In time, we are planning to deprecate this.</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Infrastructure/HTTPS-commits&diff=525298Infrastructure/HTTPS-commits2018-09-19T06:08:26Z<p>Puiterwijk: </p>
<hr />
<div>= HTTPS commits to src.fedoraproject.org =<br />
<br />
== Background ==<br />
<br />
In the past, pkgs.fedoraproject.org was the host that maintainers used to upload package sources via https and push commits via ssh. All such commits via ssh required the user to be in the 'packager' group, because the host created actual accounts for each packager, then restricted them to commits. If a user was not in that group, they wouldn't be known to the acls and would be denied. <br />
<br />
When we moved to src.fedoraproject.org with a pagure instance in front of it, this limitation was still in place, leading to users who aren't in the packagers group being able to fork packages, but being unable to push to their forks. <br />
<br />
This limitation is now removed by using https pushes, which are available for all users who have permissions to commit to packages/modules/containers/tests or forks thereof. <br />
<br />
== How it works ==<br />
<br />
fedpkg (starting with version 1.34) has the ability to fetch a OIDC token from src.fedoraproject.org and then use that token to push commits over https. <br />
You also need to make sure and have python-openidc-client => 0.6.0 installed)<br />
<br />
You will need to do your git clone with -a (anonymous) for now, and will need to using a graphical session (so your browser can be used to get the token you need). <br />
<br />
== Future plans ==<br />
<br />
Slowly over time we plan to transition all users to https pushing for commits and retire the ssh service. There will be a lot of notice for this and it will only happen after https pushing is well established and working. <br />
<br />
== FAQ ==<br />
<br />
Q: On push, git asks for a username and password, what do I enter there?<br />
<br />
A: This means you cloned with an old version of fedpkg. Do a fedpkg push (instead of git push) once after upgrading to fedpkg 1.34 or higher. Under no circumstances should you enter your FAS password in the CLI.<br />
<br />
Q: Can I do a push on a headless machine? <br />
<br />
A: Not yet. Currently you need a graphical session with a browser (firefox, chrome, etc). This will likely change down the road. <br />
<br />
Q: Can I still push via ssh?<br />
<br />
A: If you are in the packager group you can still push via ssh for now. In time, we are planning to deprecate this.<br />
<br />
Q: Can I get a token on one system and then copy it to another?<br />
<br />
A: Yes, but make sure you move it rather than copying or you keep the files in sync, since the token will be automatically refreshed and stored on-disk.</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Infrastructure/HTTPS-commits&diff=525297Infrastructure/HTTPS-commits2018-09-19T06:06:53Z<p>Puiterwijk: </p>
<hr />
<div>= HTTPS commits to src.fedoraproject.org =<br />
<br />
== Background ==<br />
<br />
In the past, pkgs.fedoraproject.org was the host that maintainers used to upload package sources via https and push commits via ssh. All such commits via ssh required the user to be in the 'packager' group, because the host created actual accounts for each packager, then restricted them to commits. If a user was not in that group, they wouldn't be known to the acls and would be denied. <br />
<br />
When we moved to src.fedoraproject.org with a pagure instance in front of it, this limitation was still in place, leading to users being able to fork packages, but being unable to push to their forks. <br />
<br />
This limitation is now removed and https pushes are available for all users who have permissions to commit to packages/modules/containers/tests and forks thereof. <br />
<br />
== How it works ==<br />
<br />
fedpkg (starting with version 1.34) has the ability to fetch a OIDC token from src.fedoraproject.org and then use that token to push commits over https. <br />
You also need to make sure and have python-openidc-client => 0.6.0 installed)<br />
<br />
You will need to do your git clone with -a (anonymous) for now, and will need to using a graphical session (so your browser can be used to get the token you need). <br />
<br />
== Future plans ==<br />
<br />
Slowly over time we plan to transition all users to https pushing for commits and retire the ssh service. There will be a lot of notice for this and it will only happen after https pushing is well established and working. <br />
<br />
== FAQ ==<br />
<br />
Q: On push, git asks for a username and password, what do I enter there?<br />
<br />
A: This means you cloned with an old version of fedpkg. Do a fedpkg push (instead of git push) once after upgrading to fedpkg 1.34 or higher. Under no circumstances should you enter your FAS password in the CLI.<br />
<br />
Q: Can I do a push on a headless machine? <br />
<br />
A: Not yet. Currently you need a graphical session with a browser (firefox, chrome, etc). This will likely change down the road. <br />
<br />
Q: Can I still push via ssh?<br />
<br />
A: If you are in the packager group you can still push via ssh for now. In time, we are planning to deprecate this.<br />
<br />
Q: Can I get a token on one system and then copy it to another?<br />
<br />
A: Yes, but make sure you move it rather than copying or you keep the files in sync, since the token will be automatically refreshed and stored on-disk.</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Infrastructure/HTTPS-commits&diff=525296Infrastructure/HTTPS-commits2018-09-19T06:06:34Z<p>Puiterwijk: some Q&A</p>
<hr />
<div>= HTTPS commits to src.fedoraproject.org =<br />
<br />
== Background ==<br />
<br />
In the past, pkgs.fedoraproject.org was the host that maintainers used to upload package sources via https and push commits via ssh. All such commits via ssh required the user to be in the 'packager' group, because the host created actual accounts for each packager, then restricted them to commits. If a user was not in that group, they wouldn't be known to the acls and would be denied. <br />
<br />
When we moved to src.fedoraproject.org with a pagure instance in front of it, this limitation was still in place, leading to users being able to fork packages, but being unable to push to their forks. <br />
<br />
This limitation is now removed and https pushes are available for all users who have permissions to commit to packages/modules/containers/tests and forks thereof. <br />
<br />
== How it works ==<br />
<br />
fedpkg (starting with version 1.34) has the ability to fetch a OIDC token from src.fedoraproject.org and then use that token to push commits over https. <br />
You also need to make sure and have python-openidc-client => 0.6.0 installed)<br />
<br />
You will need to do your git clone with -a (anonymous) for now, and will need to using a graphical session (so your browser can be used to get the token you need). <br />
<br />
== Future plans ==<br />
<br />
Slowly over time we plan to transition all users to https pushing for commits and retire the ssh service. There will be a lot of notice for this and it will only happen after https pushing is well established and working. <br />
<br />
== FAQ ==<br />
<br />
Q: On push, git asks for a username and password, what do I enter there?<br />
<br />
A: This means you cloned with an old version of fedpkg. Do a fedpkg push (instead of git push) once after upgrading to fedpkg 1.34 or higher. Under no circumstances should you enter your FAS password here.<br />
<br />
Q: Can I do a push on a headless machine? <br />
<br />
A: Not yet. Currently you need a graphical session with a browser (firefox, chrome, etc). This will likely change down the road. <br />
<br />
Q: Can I still push via ssh?<br />
<br />
A: If you are in the packager group you can still push via ssh for now. In time, we are planning to deprecate this.<br />
<br />
Q: Can I get a token on one system and then copy it to another?<br />
<br />
A: Yes, but make sure you move it rather than copying or you keep the files in sync, since the token will be automatically refreshed and stored on-disk.</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=User:Puiterwijk/test123&diff=524356User:Puiterwijk/test1232018-09-05T21:31:08Z<p>Puiterwijk: Created page with "test123"</p>
<hr />
<div>test123</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Sandbox/foobar&diff=524191Sandbox/foobar2018-08-31T17:12:03Z<p>Puiterwijk: Created page with "test123"</p>
<hr />
<div>test123</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Sandbox&diff=524190Sandbox2018-08-31T17:10:00Z<p>Puiterwijk: </p>
<hr />
<div>Testing<br />
123<br />
test123<br />
test456</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Infrastructure_Hackathon_2018&diff=516847Infrastructure Hackathon 20182018-04-24T10:58:44Z<p>Puiterwijk: </p>
<hr />
<div>This is the main page for an [[infrastructure]] hackathon in spring 2018. This hackathon is intended to help the team leap ahead for several critical Fedora and CentOS initiatives.<br />
<br />
== Working Session Notes ==<br />
<br />
[https://public.etherpad-mozilla.org/p/fedora-hack-2018 Etherpad with notes from the sessions]<br />
<br />
=== Output and outcomes ===<br />
<br />
Blog entries:<br />
* [https://www.scrye.com/wordpress/nirik/2018/04/15/fedora-infrastructure-hackfest-2018/ Blog from [[User:Kevin|Kevin Fenzi]]]<br />
* [http://blog.pingoured.fr/index.php?post/2018/04/13/Fedora-Infrastructure-Hackathon-2018 Blog from [[User:pingou|Pierre-Yves Chibon]]]<br />
* [https://blog.electronsweatshop.com/2018-fedora-infrastructure-hackathon.html Blog from [[User:Bowlofeggs|Randy Barlow]]]<br />
* [https://sinny.io/2018/04/18/things-we-did-at-fedora-infrastructure-hackathon-2018/ Blog from [[User:sinnykumari | Sinny Kumari]]]<br />
* [https://elrod.me/posts/2018-04-20-fedora-infrastructure-hackfest-2018-recap.html Blog from [[User:Codeblock | Rick Elrod]]]<br />
* [http://smoogespace.blogspot.com/2018/04/fedora-infrastructure-hackathon-day-1-5.html Blog from [[User:Smooge | Ebeneezer Smooge]]]<br />
* [https://dustymabe.com/2018/04/23/april-fedora-infrastructure-hackfest/ Blog from [[User:dustymabe | Dusty Mabe]]]<br />
* [https://patrick.uiterwijk.org/blog/2018/4/23/infra-hackfest/ Blog from [[User:puiterwijk | Patrick Uiterwijk]]]<br />
<br />
== Purpose ==<br />
Our purpose is to complete the following '''primary''' goals:<br />
<br />
=== Day 0 (Sunday) ===<br />
<br />
* Travel to hackathon<br />
<br />
=== Day 1 (Monday) ===<br />
<br />
* Go over the current lifecycle for "artifacts" and brainstorm where we can improve the developer and/or admin workflow:<br />
** Review - currently in bugzilla<br />
** New artifact request - fedpkg request-repo / fedrepo-req-admin - token issues<br />
** Commits / Building<br />
** Updates filing<br />
** CI/User feedback (waving results needs to be better)<br />
** Orphaning (orphaned.package file/listener?)<br />
** Retiring<br />
* Make such changes as we can do today, file bugs/get started on any others and note them.<br />
* Once any changes are made or planned on above: <br />
** Decide if we want to update wiki docs or move to some better place?<br />
** Identify wiki docs that need updating based on popularity.<br />
** Check db dump for strings that need indicate pages need update<br />
** Possibly decide to delete some pages<br />
** Note where things will change<br />
* Document what things we updated and changed and send to devel announce that docs/workflows are hopefully better.<br />
<br />
=== Day 2 (Tuesday) ===<br />
<br />
* Find new maintainers for jcline's applications<br />
** fedmsg<br />
** FMN<br />
** Anitya<br />
** the-new-hotness<br />
* <strike>ELK proof of concept</strike><br />
* Rawhide gating and CI<br />
<br />
=== Day 3 (Wednesday) ===<br />
<br />
* AWX setup in Fedora Infrastructure<br />
* More Rawhide Gating and CI<br />
<br />
=== Day 4 (Thursday) ===<br />
<br />
* Move some apps to OpenShift (extra goal)<br />
* Bodhi hackfest (extra goal)<br />
* Pagure hackfest (extra goal)<br />
* Jenkins jobs refactor (extra goal)<br />
<br />
=== Day 5 (Friday) ===<br />
<br />
* Knowledge transfer and finish up<br />
<br />
== Detailed Work Items & Final Attendees ==<br />
<br />
=== Deliverables ===<br />
<br />
{| class="wikitable"<br />
! Deliverables: Infra !! Task Owner !! Completion<br />
|-<br />
| Better docs, workflows and scripts for package maintainers || [[User:Kevin|kfenzi]] || {{progress bar|40}}<br />
|-<br />
| Working AWX instance in Fedora Infrastructure || [[User:Kevin|kfenzi]] || {{progress bar|100}}<br />
|-<br />
| More apps in openshift || [[User:Kevin|kfenzi]] || {{progress bar|30}}<br />
|-<br />
! Deliverables: Bodhi !! Task Owner !! Done <br />
|-<br />
| Rawhide gating of some kind || [[User:Bowlofeggs|rbarlow]] || {{progress bar|50}}<br />
|-<br />
! Deliverables: CI !! Task Owner !! Done <br />
|-<br />
| jenkins jobs refactored || [[User:Pingou|pingou]] || {{progress bar|100}}<br />
|-<br />
|}<br />
<br />
=== Done ===<br />
<br />
==== Infra ====<br />
* Roadmap for apps -> OpenShift<br />
* Bodhi web UI running in OpenShift<br />
* OpenShift 3.9 bits pulled down for new dev instance<br />
* New templates for infra issues<br />
* Killed darkserver<br />
* Jenkins in Fedora infra now redirects from old service to CentOS<br />
* Deprecated summershum<br />
<br />
==== Bodhi/gating ====<br />
* Bodhi shows missing tests<br />
* Bodhi uses waiverdb correctly<br />
* Bodhi shows waiver info<br />
* New bodhi DB model<br />
* New UI planned for Bodhi<br />
* Fixed Bodhi build testing (btest)<br />
* Bodhi can create and delete side tags<br />
* Packaged python-transitions for Bodhi side tagging transitions<br />
* Fixed cornice for testing Bodhi<br />
<br />
==== CI/Atomic/Other ====<br />
* Fixed fedmsg-meta for the all-packages pipeline<br />
* New fedmsg-meta rebase/build<br />
* adamwill owns the new yak_farmers FAS group :-)<br />
* Wrote rbac-playbook to get RPM from needed systems<br />
* Hack in place for Atomic ostree mirroring<br />
* [[User:Sinnykumari|Sinny]] trained up for Atomic releases including Fedora GA<br />
* Atomic multi-arch presence for Atomic on fp.o website planned out<br />
* Cleaned sysadmin Atomic setup<br />
<br />
=== Follow-up tickets ===<br />
<br />
* Bodhi<br />
** bodhi-push should not select Rawhide builds<br />
** API changes for side tags<br />
** can merge side tags<br />
** can expire side tags after lifetime is up<br />
** can edit/create tags (admin override)<br />
** auto-push to stable on test results<br />
** comments on update a/b results<br />
** docs for Rawhide gating<br />
** retest<br />
** fix docs to eliminate fedrepo-req<br />
* fedmsg<br />
** update creates<br />
* OpenShift 3.9<br />
** new Openstack cloud for dev (during freeze)<br />
** new dev 3.9 (during freeze)<br />
** new staging 3.9 (~end of freeze)<br />
** prod 3.9 (after freeze lifts)<br />
* retire hubs dev/stg<br />
<br />
{| class="wikitable"<br />
! Follow-up: !! Ticket <br />
|-<br />
| (Describe item that still needs to be completed) || (link to ticket)<br />
|}<br />
<br />
=== Attendees and Travel Details ===<br />
{{admon/note | Travel details | Refer to [[Infrastructure Hackathon 2018/Travel]] for itineraries and costs.}}<br />
{| class="wikitable"<br />
! Contributor !! Arrival !! Departure !! Roommate !! Notes (airfare costs) !! Paid/expensed? !! Ride with (arr/dep)<br />
|-<br />
| [[User:Smooge|Stephen Smoogen]] || Apr 8 15:03 Amtrak || Apr 13 12:20 Amtrak || [[User:Codeblock|Ricky Elrod]] || $100 (train) || || pfrields/pfrields<br />
|-<br />
| [[User:Puiterwijk|Patrick Uiterwijk]] || 2018-04-08 15:35 IAD - EI0119 || 2018-04-13 17:15 IAD - EI0118 || [[User:Kevin|Kevin Fenzi]] || $1000 (Platform dept) || yes || kfenzi/kfenzi<br />
|-<br />
| [[User:Codeblock|Ricky Elrod]] || Apr 8, 20:57, IAD, UA6031 || Apr 13, 12:50, IAD, UA4995 || [[User:Smooge|Stephen Smoogen]] || $250 (Platform dept) || yes || relrod/relrod<br />
|-<br />
| [[User:Dustymabe|Dusty Mabe]] || Apr 8 15:03 Amtrak || Apr 13 12:20 Amtrak || || $100 (train) || || pfrields/pfrields<br />
|-<br />
| [[User:Rbarlow|Randy Barlow]] || Apr 8 15:03 Amtrak || Apr 13 12:20 Amtrak || [[User:Pingou|Pierre-Yves Chibon]] || $100 (train) || || pfrields/pfrields<br />
|-<br />
| [[User:Kevin|Kevin Fenzi]] || Apr 8 15:47 UA250 || Apr 13 17:05 UA251 || [[User:Puiterwijk|Patrick Uiterwijk]] || $600 (Platform dept) || yes || kfenzi/kfenzi<br />
|-<br />
| [[User:Pingou|Pierre-Yves Chibon]] || Apr 7 15:50 - AF0054 || Apr 13 17:40 - AF6697 || [[User:Rbarlow|Randy Barlow]] || $1200 (flight + train) (Platform dept) || yes (flight) || kfenzi/kfenzi<br />
|-<br />
| [[User:Sinnykumari|Sinny Kumari]] || Apr 8 15:35 - IAD(QR 707) || Apr 13 20:25 - IAD(QR 708) || || $1150 (flight) (Platform dept) || yes || kfenzi/kfenzi<br />
|-<br />
| [[User:Ryanlerch|Ryan Lerch]] || April 8 17:58 QF3083/AA1362 IAD || Apr 13 19:05 UA719 IAD || [[User:Bstinson|Brian Stinson]] || $2283 (Platform dept) || yes || relrod/kfenzi<br />
|-<br />
| [[User:Jperrin|Jim Perrin]] || || || || $700 - $800 (handled from OSAS) || yes || jperrin/jperrin<br />
|-<br />
| [[User:Bstinson|Brian Stinson]] || Apr 8 14:21 AA2354 - IAD || Apr 13 11:35 AA1556 - IAD || [[User:Ryanlerch|Ryan Lerch]] || $600-$700 (OSAS) || yes || kfenzi/relrod<br />
|-<br />
| [[User:mattdm|Matthew Miller]] || Apr 8 18:08 Amtrak || Apr '''12''' 8:00 Amtrak || || (FPL budget)|| yes || pfrields/pfrields<br />
|}<br />
<br />
== Planning Prerequisites ==<br />
<br />
See the [[How to organize a FAD]] list; you can keep your to-do list here.<br />
<br />
* Work out budget<br />
** Travel fares -- ~$? (nb to advise)<br />
** Lodging -- 8 rooms * $129/night + tax * 5 nights = approx. $6500<br />
** Meals -- est. $2500?<br />
** Rental cars -- $800-1000 max for two vans<br />
** Meeting room -- $1175 for week (sponsored by Ansible)<br />
** '''TOTAL: ~$10K from Fedora budget'''<br />
* Decide on Dates and Location<br />
** April 9-13<br />
** Arrivals: Sunday April 8; departures: Friday April 13<br />
* Arrange Facilities<br />
** Fredericksburg:<br />
*** Travel<br />
**** Recommended airport: Washington Dulles (IAD), about 68 miles (110km); also Reagan National (DCA), about 55 miles (90km); and Richmond International (RIC), about 70 miles (115km)<br />
**** IAD recommended for international travelers<br />
*** Workspace<br />
**** [http://president.umw.edu/events/campus-event-venues/stafford-campus/ University of Mary Washington - Stafford Graduate Campus] -- corporate classroom - $125/half-day<br />
*** Lodging<br />
**** [https://hiltongardeninn3.hilton.com/en/hotels/virginia/hilton-garden-inn-fredericksburg-DCAFHGI/index.html Hilton Garden Inn]<br />
*** Rental vehicles<br />
**** ~$1000 for two minivan rentals contract carrier (max)<br />
*** Social (Thursday)<br />
**** https://strangewaysbrewing.com/book-events/fxbg-book-events/<br />
**** or other local pub/restaurant<br />
* List Resources<br />
* Be Somewhat Structured<br />
* Arrange Lodging<br />
* Arrange Refreshments<br />
* <strike>Arrange a Social Event</strike> -- N/A<br />
<br />
== Plan ==<br />
# '''Location:''' Fredericksburg, VA<br />
#* Lodging: [https://hiltongardeninn3.hilton.com/en/hotels/virginia/hilton-garden-inn-fredericksburg-DCAFHGI/index.html Hilton Garden Inn Fredericksburg]<br />
# '''Date:''' April 9-13<br />
#* Arrivals: Sunday April 8<br />
# '''Remote Attendees:''' {{fpchat|#fedora-admin}}<br />
# '''Schedule'''<br />
#* Event starts 09:30 daily<br />
#* Event ends by 12:00pm Friday April 13, to allow for travel outbound<br />
<br />
== Logistics ==<br />
<br />
* '''Travel to hotel:''' Travelers will group by arrival and travel via rental car from IAD (Dulles, VA) to the hotel in Fredericksburg. Travel time on Sunday afternoon is between 70-90 minutes depending on traffic conditions.<br />
* '''Snacks/Beverages:''' Limited access due to the nature of the graduate campus. Monday will give us an idea how we can accommodate during the event.<br />
* '''Meals:'''<br />
** Breakfast before event -- venues TBD, meet in lobby of hotel at 08:15 daily<br />
** Lunch -- venues TBD, 12:30-13:45 daily<br />
** Dinner -- venues TBD after event ends (17:30)<br />
<br />
== Travel estimates ==<br />
<br />
{| class="wikitable"<br />
! Contributor !! Taxi/transport (to/from home) !! Airfare !! Taxi/transport (to/from site) !! Parking !! Other <br />
|-<br />
| || || || || ||<br />
|}<br />
<br />
# '''Travel:''' (TOTAL) (est)<br />
# '''Housing:''' (TOTAL) (est)<br />
# '''Space:'''<br />
#* (COST) - Supplied by (LOCATION)<br />
# '''Supplies:'''<br />
#* N/A<br />
# '''Food:''' (TOTAL) (est -- to be paid by Fedora Engineering budget)<br />
<br />
''Total budget: (TOTAL) estimated''<br />
<br />
<br />
[[Category:FAD]]</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=MediaWiki:Sidebar&diff=515514MediaWiki:Sidebar2018-04-10T21:55:41Z<p>Puiterwijk: whatcanido</p>
<hr />
<div>* Links<br />
** https://getfedora.org/|Get Fedora<br />
** https://docs.fedoraproject.org/|Fedora Docs<br />
** https://fedoramagazine.org/|Fedora Magazine<br />
** https://whatcanidoforfedora.org/|What Can I Do?<br />
<br />
* Subprojects<br />
** Ambassadors|Ambassadors<br />
** CommOps|Community Operations<br />
** Design|Design<br />
** DocsProject|Documentation<br />
** EPEL|EPEL<br />
** Infrastructure|Infrastructure<br />
** I18N|Internationalization<br />
** L10N|Localization<br />
** Marketing|Marketing<br />
** Magazine|Magazine<br />
** PackageMaintainers|Package Maintainers<br />
** QA|Quality Assurance<br />
** Websites|Websites<br />
** Atomic<br />
** Server<br />
** Workstation<br />
** Projects|All projects</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=MediaWiki:Sidebar&diff=515513MediaWiki:Sidebar2018-04-10T21:54:13Z<p>Puiterwijk: simplify</p>
<hr />
<div>* Links<br />
** https://getfedora.org/|Get Fedora<br />
** https://docs.fedoraproject.org/|Fedora Docs<br />
** https://fedoramagazine.org/|Fedora Magazine<br />
<br />
* Subprojects<br />
** Ambassadors|Ambassadors<br />
** CommOps|Community Operations<br />
** Design|Design<br />
** DocsProject|Documentation<br />
** EPEL|EPEL<br />
** Infrastructure|Infrastructure<br />
** I18N|Internationalization<br />
** L10N|Localization<br />
** Marketing|Marketing<br />
** Magazine|Magazine<br />
** PackageMaintainers|Package Maintainers<br />
** QA|Quality Assurance<br />
** Websites|Websites<br />
** Atomic<br />
** Server<br />
** Workstation<br />
** Projects|All projects</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Package_update_HOWTO&diff=514869Package update HOWTO2018-03-30T14:23:29Z<p>Puiterwijk: Fix NVR_LIST</p>
<hr />
<div>This document shows how to submit an update for a package you maintain in Fedora. It assumes you already have a package in the Fedora repositories. It is not a guide to using the Fedora package source control system: see the [[Package maintenance guide]] for that.<br />
<br />
* For details of the policy on requirements for updates at various stages of the [[Fedora Release Life Cycle]], refer to [[Updates Policy]].<br />
<br />
== Overview ==<br />
<br />
This page is intended for new and existing package maintainers. Testers and regular users may be interested in the [[QA:Updates_Testing|updates-testing]] repository and the [[QA:Update_feedback_guidelines|update feedback guidelines]]. This page specifically covers the update submission process.<br />
<br />
There are two significantly different package update submission workflows in Fedora:<br />
<br />
* [[Releases/Rawhide|Rawhide]], and [[Releases/Branched|Branched]] up to the [[Updates Policy#Bodhi enabling|Bodhi enabling point]]<br />
* [[Releases/Branched|Branched]] releases after the Alpha change deadline, and stable releases<br />
<br />
The repository layouts differ somewhat for Rawhide, Branched and stable releases, but the update workflows split up as described above.<br />
<br />
== Rawhide and early Branched ==<br />
<br />
The package update workflow for Rawhide and Branched before the ''Bodhi enabling point'' is simple:<br />
<br />
# Build the package with {{command|fedpkg build}} (see the [[Package maintenance guide]] for more details)<br />
<br />
This is all you need to do. Your package will appear in the next daily compose of Rawhide or Branched and will be used in any image composes built from that tree.<br />
<br />
== Later Branched and stable releases ==<br />
<br />
At the [[Updates Policy#Bodhi enabling|Bodhi enabling point]], the [[Bodhi]] update feedback system is enabled by [[ReleaseEngineering|Release Engineering]] and builds submitted with {{command|fedpkg build}} are no longer automatically sent to any official [[Repositories|repository]]. The update workflow for releases of this type is:<br />
<br />
{{admon/tip|Fedora account name|{{command|fedpkg}} should be able to discover your [[Account_System|Fedora account system]] user name from the {{filename|~/.fedora.cert}} file set up by {{command|fedora-packager-setup}} when you first [[Join_the_package_collection_maintainers#Install_the_client_tools_.28Koji.29_and_set_up_your_certificate|configured your system for packaging]]. If this fails for any reason, you can specify it with {{command|--user (username)}}. For the {{command|bodhi}} command line tool, you may need to specify your Fedora user name with {{command|-u (username)}} if it differs from your system user name.}}<br />
<br />
# Build the package with {{command|fedpkg build}}<br />
# Submit an update for the package with {{command|fedpkg update}}, the [https://admin.fedoraproject.org/updates/ Bodhi web interface], or the [https://fedorahosted.org/bodhi/wiki/CLI Bodhi CLI tool]. This causes the package to be sent to the [[Repositories#updates-testing|''updates-testing'']] repository<br />
# Monitor the update's status and the feedback you receive via the web interface or the emails that are sent to you, and modify it with updated or additional builds if necessary<br />
# After the update meets the criteria in the [[Updates Policy]] and you are satisfied it should be released as a stable update, submit the update to ''[[Repositories#stable|stable]]'' with {{command|bodhi -R stable}} or the web interface<br />
<br />
{{admon/important|Updating inter-dependent packages|If a package you wish to update requires other package(s) to be rebuilt before it or they will work properly, you '''must''' submit the builds together as a multi-package update. See [[#multi|below]] for more details on this.}}<br />
<br />
=== Update attributes ===<br />
<br />
At the time you submit the update, you will be asked for several attributes. The type of the update should be fairly self-explanatory: either it fixes bugs, adds new features, or is a new package.<br />
<br />
If you are asked whether you want to send the update to ''updates-testing'' or ''stable'', this is a no-op: all updates now go through ''updates-testing''. It does not matter what you choose.<br />
<br />
There are several schools of thought on filling out the update description. Some would suggest you consider the target audience: for a stable release, in particular, many Fedora users will see this text, and many of them may not be particularly familiar with your package. Consider not simply describing literally the changes in the update, but explaining as if to an outsider why your are updating the package, what benefits it will bring to them (if any), and anything they may want to note in order to have a smooth update experience.<br />
<br />
If you associate one or more bug reports with your update, Bodhi will post comments into Bugzilla to alert those following the bug reports that an update is available. If you mark your update as fixing the bug(s), Bodhi will move the report(s) through the '''MODIFIED''', '''ON_QA''' and '''CLOSED ERRATA''' states of the [[BugZappers/BugStatusWorkFlow|bug workflow]] as your update reaches various points in the process. Using this mechanism can be very useful both for you and for users of your package.<br />
<br />
You may set a ''karma'' (feedback) level at which the update will automatically be submitted to ''stable''. This is optional. If you choose to use it, please carefully consider an appropriate feedback level. For a relatively obscure package which is quite stable, 1 or 2 may be an appropriate value. For a popular, sensitive and complex package such as {{package|firefox}} or the {{package|kernel}}, the default of 3 may be insufficient and a choice of 5 or even 10 may be appropriate.<br />
<br />
=== Who will receive your update, when? ===<br />
<br />
When a release is in Branched state, the ''updates-testing'' repository is enabled by default so most users will see the package, but only packages from the stable ''fedora'' repository are used in building milestone releases (Alpha, Beta and Final) and nightly images.<br />
<br />
Where a package goes when it is marked as ''stable'' differs between Branched and stable releases. In Branched releases, ''stable'' packages are pushed to the base ''fedora'' repository. In stable releases, ''stable'' packages are pushed to the ''updates'' repository. However, from the point of view of the packager, this is an insignificant implementation detail. For more details, see [[Repositories]].<br />
<br />
When a release is in stable state, the ''updates-testing'' repository is disabled by default, but [[QA]] team members and others run with it enabled in order to provide testing and Bodhi feedback. The main user population will see your update only when it passes Bodhi, is marked as ''stable'' and reaches the ''updates'' repository.<br />
<br />
{{anchor|multi}}<br />
=== Updating inter-dependent packages ===<br />
<br />
If an update you wish to submit would cause a dependency issue of any kind (a strict package dependency error, or simply another package failing to operate correctly) if updated alone, you must not submit the package as a single-package update. You must always collect all inter-dependent or related packages together into a single multi-package update, such that no user will face problems if they install all the packages in the update together.<br />
<br />
For example: if you maintain a package ''libfoo'' which the package ''bar'' depends on, and you need to update ''libfoo'', you should check that ''bar'' continues to function correctly with the updated version of ''libfoo''. If it does not, you must ensure the appropriate changes are made to ''bar'', and include the updated ''bar'' in your update along with the updated ''libfoo''.<br />
<br />
The ''fedpkg'' tool does not handle multi-package updates. You can add multiple packages to an update using the [https://admin.fedoraproject.org/updates/ Bodhi web application], or the {{command|bodhi}} command line tool. You can pass as many package names as you like to the {{command|bodhi --new}} to create a new multi-package update, or use {{command|bodhi --edit}} to edit an existing update.<br />
<br />
It is possible you will run into problems with permissions when trying to add builds of packages you do not have commit privileges for to an update, or trying to add a build for a package you do have privileges for to someone else's update. If you encounter a situation like this, you should contact the [[ReleaseEngineering|release engineering]] team or a proven packager for help.<br />
<br />
You may need a ''buildroot override'' to complete a multi-package update successfully. For instance in the case described above, you may need to rebuild ''bar'' against the new ''libfoo'' package and submit both packages together as a multi-package update. However, in the normal course of events, you would not be able to build another package against your new ''libfoo'' build until it reached the [[Repositories#stable|''stable'']] state. To resolve this dilemma, you can request a buildroot override, which causes the ''libfoo'' build to be included in the buildroot for a short time in order to get the ''bar'' package build done.<br />
<br />
You can request a buildroot override with bodhi: {{command|bodhi --buildroot-override<nowiki>=</nowiki>(name-version-release) --duration<nowiki>=</nowiki>2 --notes<nowiki>=</nowiki>"Useful details."}} This would submit a buildroot override with a duration of two days. Buildroot overrides are usually granted within 15-30 minutes of submission. If you submit an override request with the bodhi tool, it will suggest a command that will let you monitor when the package appears in the buildroot, so you can fire your dependent build at the appropriate time.<br />
<br />
You can also request buildroot overrides from the [https://admin.fedoraproject.org/updates/ Bodhi web application].<br />
<br />
The [[Bodhi/BuildRootOverrides|buildroot override instructions]] explain the buildroot override process in more detail.<br />
<br />
=== Handling feedback from automated tests ===<br />
<br />
Fedora's automated testing systems, [[Taskotron]] and [[OpenQA]], may run automated tests on your update. Several of the [[Taskotron/Tasks]] are documented. The openQA tests are functional tests of some critical [[Workstation]] and [[Server]] features.<br />
<br />
In the Bodhi web interface, updates have a ''Automated Tests'' tab which displays the results of all automated tests. Tests shown with a red background failed. The tests are not all 100% accurate, but they are fairly often correct. If you see a failure, it is a very good idea to click on the result (which will take you to a detailed log) and investigate the issue. If you are unsure what the test indicates, you can contact the [[QA]] team for help.<br />
<br />
==== Waive a result ====<br />
<br />
At present, a failure of the ''dist.rpmdeplint'', ''dist.abicheck'', or ''org.centos.prod.ci.pipeline.complete'' tests will prevent your update from being released. On the update's ''Details'' page in the Bodhi web interface, the '''Test Gating Status''' will be shown as ''N of N required tests failed''. If you are sure such a failure is a false one, you can 'waive' the result using the {{code|waiverdb-cli}} tool, from the {{package|waiverdb-cli}} package (there is [https://github.com/fedora-infra/bodhi/pull/2095 work pending] to be able to waiver more easily, directly from the Bodhi UI).<br />
<br />
You can submit a waiver for a failing result with {{pkg|waiverdb-cli}} specifying the {{code|subject}} and the {{code|testcase}}:<br />
<br />
waiverdb-cli -t YOUR_TESTCASE_HERE -s '{"item": "this-is-the-subject", "type": "also-this-is-part-of-the-subject"}' -p "fedora-26" -c "This is fine"<br />
<br />
Example:<br />
<br />
waiverdb-cli -t dist.rpmdeplint -s '{"item": "python-requests-1.2.3-1.fc26", "type": "koji_build"}' -p "fedora-26" -c "This is fine"<br />
<br />
You can also waive a failing result by result's id, which you can retrieve from resultsdb with curl. To do that, you'll need the {{code|testcase}} name and the {{code|nvr}}. For example:<br />
<br />
curl "https://taskotron.fedoraproject.org/resultsdb_api/api/v2.0/results?testcases=dist.python-versions&item=python-alembic-0.9.7-1.fc27" | jq ".data[0].id"<br />
<br />
This should print out the {{code|result_id}} of the failing result. You can then submit a waiver for this failing result with {{pkg|waiverdb-cli}}<br />
<br />
waiverdb-cli -p fedora-27 -r YOUR_ID_HERE -c "This is fine."<br />
<br />
Also, if you enabled automatic stable push at a karma threshold, this will be disabled if any automated test fails. If you have examined the result and you are sure it is a false one and there is no problem with the package, you may re-enable the automatic push mechanism or submit the package to ''stable'' manually once it meets the other requirements of the [[Updates Policy]].<br />
<br />
==== Waive the absence of a result ====<br />
<br />
Submitting a waiver using subject/testcase allows to waive the absence of a result (eg. the test never ran for some reason, so there is no result item).<br />
<br />
If which testcase you should be specified it is not clear/known, it is possible to run this python script, chainging it with the corrects parameter:<br />
<br />
#!/usr/bin/env python<br />
""" Ask a question of greenwave. """<br />
# Usage: either modify and set PRODUCT_VERSION and NVR_LIST and run, or pass version as first arg and then NVRs as further args<br />
import pprint<br />
import requests<br />
import sys<br />
PRODUCT_VERSION = 'fedora-27' if len(sys.argv) == 1 else sys.argv[1]<br />
NVR_LIST = [] or sys.argv[2:] # Insert your NVRs here, or pass them via command line args<br />
for nvr in NVR_LIST:<br />
url = (<br />
'https://greenwave-web-greenwave.app.os.fedoraproject.org/'<br />
'api/v1.0/decision')<br />
payload = dict(<br />
#verbose=True,<br />
decision_context='bodhi_update_push_stable',<br />
product_version=PRODUCT_VERSION,<br />
subject=[{'item': nvr, 'type': 'koji_build'}],<br />
)<br />
response = requests.post(url, json=payload)<br />
print("-" * 40)<br />
print(nvr, response, response.status_code)<br />
data = response.json()<br />
print(pprint.pformat(data))<br />
<br />
The output will show that Greenwave is requiring a specific testcase to run, but it cannot find a result for it (neither pass nor failure). So now it is possible to submit a waiver with the specified testcase in the output and the subject already known.<br />
<br />
==== Troubleshooting ====<br />
<br />
If you run the {{code|waiverdb-cli}} tool and it gives you the following error:<br />
<br />
Error: The config option "resultsdb_api_url" is required<br />
<br />
Edit {{code|/etc/waiverdb/client.conf}} and add the following line:<br />
<br />
resultsdb_api_url=https://taskotron.fedoraproject.org/resultsdb_api/api/v2.0<br />
<br />
=== Branched milestone freezes ===<br />
<br />
For a short period before each milestone release, the stable [[Repositories#fedora|''fedora'']] repository is frozen. These periods are shown as the [[Milestone freezes]] (Beta Freeze, Final Freeze) on schedules. During these periods, builds will not be marked ''stable'' and pushed from [[Repositories#updates-testing|''updates-testing'']] to ''fedora'' even after being submitted manually or automatically. In the normal course of events, they will be pushed after the milestone release is approved at a [[Go_No_Go_Meeting]]. If you believe your update deserves to break a milestone freeze, a ''freeze exception'' may be granted through the [[QA:SOP_freeze_exception_bug_process|freeze exception process]]. Accepted release blocking bugs are granted the same status through the [[QA:SOP_blocker_bug_process|blocker bug process]].<br />
<br />
For more on the Fedora development process, see [[Fedora Release Life Cycle]].<br />
<br />
{{admon/tip| <br />
If you are unsure whether your build is currently considered ''stable'' for a given release, you can check with {{command|koji latest-pkg fXX}} (where XX is the release).}}<br />
<br />
== Security updates ==<br />
<br />
There is an additional process that layers over the regular update process for bugs identified as security issues. If a bug is assigned to you that blocks a [[Security Tracking Bugs|security tracking bug]], you must follow that process in addition to this one.<br />
<br />
== New package submissions ==<br />
<br />
If you want to build a new package, but you aren't sure which releases to send it to:<br />
<br />
* New packages should always be built for Rawhide<br />
* New packages can be built for Branched and stable releases if adding them would provide value to users of those releases without significant risk of causing harm<br />
<br />
The submission process for new packages, after they have passed the [[Package_Review_Process]] and been [[Package_SCM_admin_requests|given an SCM repository]], is exactly the same as that for package updates.<br />
<br />
== Consider creating a package test plan ==<br />
<br />
If you [[QA:SOP_test_case_creation|create test cases]] for your package, and [[QA:SOP_package_test_plan_creation|categorize them appropriately]], they will be automatically linked in Bodhi, so that testers will have some guidance for planned update testing.<br />
<br />
[[Category:Package Maintainers]]</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Package_update_HOWTO&diff=514868Package update HOWTO2018-03-30T14:21:06Z<p>Puiterwijk: Allow version via arg</p>
<hr />
<div>This document shows how to submit an update for a package you maintain in Fedora. It assumes you already have a package in the Fedora repositories. It is not a guide to using the Fedora package source control system: see the [[Package maintenance guide]] for that.<br />
<br />
* For details of the policy on requirements for updates at various stages of the [[Fedora Release Life Cycle]], refer to [[Updates Policy]].<br />
<br />
== Overview ==<br />
<br />
This page is intended for new and existing package maintainers. Testers and regular users may be interested in the [[QA:Updates_Testing|updates-testing]] repository and the [[QA:Update_feedback_guidelines|update feedback guidelines]]. This page specifically covers the update submission process.<br />
<br />
There are two significantly different package update submission workflows in Fedora:<br />
<br />
* [[Releases/Rawhide|Rawhide]], and [[Releases/Branched|Branched]] up to the [[Updates Policy#Bodhi enabling|Bodhi enabling point]]<br />
* [[Releases/Branched|Branched]] releases after the Alpha change deadline, and stable releases<br />
<br />
The repository layouts differ somewhat for Rawhide, Branched and stable releases, but the update workflows split up as described above.<br />
<br />
== Rawhide and early Branched ==<br />
<br />
The package update workflow for Rawhide and Branched before the ''Bodhi enabling point'' is simple:<br />
<br />
# Build the package with {{command|fedpkg build}} (see the [[Package maintenance guide]] for more details)<br />
<br />
This is all you need to do. Your package will appear in the next daily compose of Rawhide or Branched and will be used in any image composes built from that tree.<br />
<br />
== Later Branched and stable releases ==<br />
<br />
At the [[Updates Policy#Bodhi enabling|Bodhi enabling point]], the [[Bodhi]] update feedback system is enabled by [[ReleaseEngineering|Release Engineering]] and builds submitted with {{command|fedpkg build}} are no longer automatically sent to any official [[Repositories|repository]]. The update workflow for releases of this type is:<br />
<br />
{{admon/tip|Fedora account name|{{command|fedpkg}} should be able to discover your [[Account_System|Fedora account system]] user name from the {{filename|~/.fedora.cert}} file set up by {{command|fedora-packager-setup}} when you first [[Join_the_package_collection_maintainers#Install_the_client_tools_.28Koji.29_and_set_up_your_certificate|configured your system for packaging]]. If this fails for any reason, you can specify it with {{command|--user (username)}}. For the {{command|bodhi}} command line tool, you may need to specify your Fedora user name with {{command|-u (username)}} if it differs from your system user name.}}<br />
<br />
# Build the package with {{command|fedpkg build}}<br />
# Submit an update for the package with {{command|fedpkg update}}, the [https://admin.fedoraproject.org/updates/ Bodhi web interface], or the [https://fedorahosted.org/bodhi/wiki/CLI Bodhi CLI tool]. This causes the package to be sent to the [[Repositories#updates-testing|''updates-testing'']] repository<br />
# Monitor the update's status and the feedback you receive via the web interface or the emails that are sent to you, and modify it with updated or additional builds if necessary<br />
# After the update meets the criteria in the [[Updates Policy]] and you are satisfied it should be released as a stable update, submit the update to ''[[Repositories#stable|stable]]'' with {{command|bodhi -R stable}} or the web interface<br />
<br />
{{admon/important|Updating inter-dependent packages|If a package you wish to update requires other package(s) to be rebuilt before it or they will work properly, you '''must''' submit the builds together as a multi-package update. See [[#multi|below]] for more details on this.}}<br />
<br />
=== Update attributes ===<br />
<br />
At the time you submit the update, you will be asked for several attributes. The type of the update should be fairly self-explanatory: either it fixes bugs, adds new features, or is a new package.<br />
<br />
If you are asked whether you want to send the update to ''updates-testing'' or ''stable'', this is a no-op: all updates now go through ''updates-testing''. It does not matter what you choose.<br />
<br />
There are several schools of thought on filling out the update description. Some would suggest you consider the target audience: for a stable release, in particular, many Fedora users will see this text, and many of them may not be particularly familiar with your package. Consider not simply describing literally the changes in the update, but explaining as if to an outsider why your are updating the package, what benefits it will bring to them (if any), and anything they may want to note in order to have a smooth update experience.<br />
<br />
If you associate one or more bug reports with your update, Bodhi will post comments into Bugzilla to alert those following the bug reports that an update is available. If you mark your update as fixing the bug(s), Bodhi will move the report(s) through the '''MODIFIED''', '''ON_QA''' and '''CLOSED ERRATA''' states of the [[BugZappers/BugStatusWorkFlow|bug workflow]] as your update reaches various points in the process. Using this mechanism can be very useful both for you and for users of your package.<br />
<br />
You may set a ''karma'' (feedback) level at which the update will automatically be submitted to ''stable''. This is optional. If you choose to use it, please carefully consider an appropriate feedback level. For a relatively obscure package which is quite stable, 1 or 2 may be an appropriate value. For a popular, sensitive and complex package such as {{package|firefox}} or the {{package|kernel}}, the default of 3 may be insufficient and a choice of 5 or even 10 may be appropriate.<br />
<br />
=== Who will receive your update, when? ===<br />
<br />
When a release is in Branched state, the ''updates-testing'' repository is enabled by default so most users will see the package, but only packages from the stable ''fedora'' repository are used in building milestone releases (Alpha, Beta and Final) and nightly images.<br />
<br />
Where a package goes when it is marked as ''stable'' differs between Branched and stable releases. In Branched releases, ''stable'' packages are pushed to the base ''fedora'' repository. In stable releases, ''stable'' packages are pushed to the ''updates'' repository. However, from the point of view of the packager, this is an insignificant implementation detail. For more details, see [[Repositories]].<br />
<br />
When a release is in stable state, the ''updates-testing'' repository is disabled by default, but [[QA]] team members and others run with it enabled in order to provide testing and Bodhi feedback. The main user population will see your update only when it passes Bodhi, is marked as ''stable'' and reaches the ''updates'' repository.<br />
<br />
{{anchor|multi}}<br />
=== Updating inter-dependent packages ===<br />
<br />
If an update you wish to submit would cause a dependency issue of any kind (a strict package dependency error, or simply another package failing to operate correctly) if updated alone, you must not submit the package as a single-package update. You must always collect all inter-dependent or related packages together into a single multi-package update, such that no user will face problems if they install all the packages in the update together.<br />
<br />
For example: if you maintain a package ''libfoo'' which the package ''bar'' depends on, and you need to update ''libfoo'', you should check that ''bar'' continues to function correctly with the updated version of ''libfoo''. If it does not, you must ensure the appropriate changes are made to ''bar'', and include the updated ''bar'' in your update along with the updated ''libfoo''.<br />
<br />
The ''fedpkg'' tool does not handle multi-package updates. You can add multiple packages to an update using the [https://admin.fedoraproject.org/updates/ Bodhi web application], or the {{command|bodhi}} command line tool. You can pass as many package names as you like to the {{command|bodhi --new}} to create a new multi-package update, or use {{command|bodhi --edit}} to edit an existing update.<br />
<br />
It is possible you will run into problems with permissions when trying to add builds of packages you do not have commit privileges for to an update, or trying to add a build for a package you do have privileges for to someone else's update. If you encounter a situation like this, you should contact the [[ReleaseEngineering|release engineering]] team or a proven packager for help.<br />
<br />
You may need a ''buildroot override'' to complete a multi-package update successfully. For instance in the case described above, you may need to rebuild ''bar'' against the new ''libfoo'' package and submit both packages together as a multi-package update. However, in the normal course of events, you would not be able to build another package against your new ''libfoo'' build until it reached the [[Repositories#stable|''stable'']] state. To resolve this dilemma, you can request a buildroot override, which causes the ''libfoo'' build to be included in the buildroot for a short time in order to get the ''bar'' package build done.<br />
<br />
You can request a buildroot override with bodhi: {{command|bodhi --buildroot-override<nowiki>=</nowiki>(name-version-release) --duration<nowiki>=</nowiki>2 --notes<nowiki>=</nowiki>"Useful details."}} This would submit a buildroot override with a duration of two days. Buildroot overrides are usually granted within 15-30 minutes of submission. If you submit an override request with the bodhi tool, it will suggest a command that will let you monitor when the package appears in the buildroot, so you can fire your dependent build at the appropriate time.<br />
<br />
You can also request buildroot overrides from the [https://admin.fedoraproject.org/updates/ Bodhi web application].<br />
<br />
The [[Bodhi/BuildRootOverrides|buildroot override instructions]] explain the buildroot override process in more detail.<br />
<br />
=== Handling feedback from automated tests ===<br />
<br />
Fedora's automated testing systems, [[Taskotron]] and [[OpenQA]], may run automated tests on your update. Several of the [[Taskotron/Tasks]] are documented. The openQA tests are functional tests of some critical [[Workstation]] and [[Server]] features.<br />
<br />
In the Bodhi web interface, updates have a ''Automated Tests'' tab which displays the results of all automated tests. Tests shown with a red background failed. The tests are not all 100% accurate, but they are fairly often correct. If you see a failure, it is a very good idea to click on the result (which will take you to a detailed log) and investigate the issue. If you are unsure what the test indicates, you can contact the [[QA]] team for help.<br />
<br />
==== Waive a result ====<br />
<br />
At present, a failure of the ''dist.rpmdeplint'', ''dist.abicheck'', or ''org.centos.prod.ci.pipeline.complete'' tests will prevent your update from being released. On the update's ''Details'' page in the Bodhi web interface, the '''Test Gating Status''' will be shown as ''N of N required tests failed''. If you are sure such a failure is a false one, you can 'waive' the result using the {{code|waiverdb-cli}} tool, from the {{package|waiverdb-cli}} package (there is [https://github.com/fedora-infra/bodhi/pull/2095 work pending] to be able to waiver more easily, directly from the Bodhi UI).<br />
<br />
You can submit a waiver for a failing result with {{pkg|waiverdb-cli}} specifying the {{code|subject}} and the {{code|testcase}}:<br />
<br />
waiverdb-cli -t YOUR_TESTCASE_HERE -s '{"item": "this-is-the-subject", "type": "also-this-is-part-of-the-subject"}' -p "fedora-26" -c "This is fine"<br />
<br />
Example:<br />
<br />
waiverdb-cli -t dist.rpmdeplint -s '{"item": "python-requests-1.2.3-1.fc26", "type": "koji_build"}' -p "fedora-26" -c "This is fine"<br />
<br />
You can also waive a failing result by result's id, which you can retrieve from resultsdb with curl. To do that, you'll need the {{code|testcase}} name and the {{code|nvr}}. For example:<br />
<br />
curl "https://taskotron.fedoraproject.org/resultsdb_api/api/v2.0/results?testcases=dist.python-versions&item=python-alembic-0.9.7-1.fc27" | jq ".data[0].id"<br />
<br />
This should print out the {{code|result_id}} of the failing result. You can then submit a waiver for this failing result with {{pkg|waiverdb-cli}}<br />
<br />
waiverdb-cli -p fedora-27 -r YOUR_ID_HERE -c "This is fine."<br />
<br />
Also, if you enabled automatic stable push at a karma threshold, this will be disabled if any automated test fails. If you have examined the result and you are sure it is a false one and there is no problem with the package, you may re-enable the automatic push mechanism or submit the package to ''stable'' manually once it meets the other requirements of the [[Updates Policy]].<br />
<br />
==== Waive the absence of a result ====<br />
<br />
Submitting a waiver using subject/testcase allows to waive the absence of a result (eg. the test never ran for some reason, so there is no result item).<br />
<br />
If which testcase you should be specified it is not clear/known, it is possible to run this python script, chainging it with the corrects parameter:<br />
<br />
#!/usr/bin/env python<br />
""" Ask a question of greenwave. """<br />
# Usage: either modify and set PRODUCT_VERSION and NVR_LIST and run, or pass version as first arg and then NVRs as further args<br />
import pprint<br />
import requests<br />
import sys<br />
PRODUCT_VERSION = 'fedora-27' if len(sys.argv) == 1 else sys.argv[1]<br />
NVR_LIST = [] or sys.argv[1:] # Insert your NVRs here, or pass them via command line args<br />
for nvr in NVR_LIST:<br />
url = (<br />
'https://greenwave-web-greenwave.app.os.fedoraproject.org/'<br />
'api/v1.0/decision')<br />
payload = dict(<br />
#verbose=True,<br />
decision_context='bodhi_update_push_stable',<br />
product_version=PRODUCT_VERSION,<br />
subject=[{'item': nvr, 'type': 'koji_build'}],<br />
)<br />
response = requests.post(url, json=payload)<br />
print("-" * 40)<br />
print(nvr, response, response.status_code)<br />
data = response.json()<br />
print(pprint.pformat(data))<br />
<br />
The output will show that Greenwave is requiring a specific testcase to run, but it cannot find a result for it (neither pass nor failure). So now it is possible to submit a waiver with the specified testcase in the output and the subject already known.<br />
<br />
==== Troubleshooting ====<br />
<br />
If you run the {{code|waiverdb-cli}} tool and it gives you the following error:<br />
<br />
Error: The config option "resultsdb_api_url" is required<br />
<br />
Edit {{code|/etc/waiverdb/client.conf}} and add the following line:<br />
<br />
resultsdb_api_url=https://taskotron.fedoraproject.org/resultsdb_api/api/v2.0<br />
<br />
=== Branched milestone freezes ===<br />
<br />
For a short period before each milestone release, the stable [[Repositories#fedora|''fedora'']] repository is frozen. These periods are shown as the [[Milestone freezes]] (Beta Freeze, Final Freeze) on schedules. During these periods, builds will not be marked ''stable'' and pushed from [[Repositories#updates-testing|''updates-testing'']] to ''fedora'' even after being submitted manually or automatically. In the normal course of events, they will be pushed after the milestone release is approved at a [[Go_No_Go_Meeting]]. If you believe your update deserves to break a milestone freeze, a ''freeze exception'' may be granted through the [[QA:SOP_freeze_exception_bug_process|freeze exception process]]. Accepted release blocking bugs are granted the same status through the [[QA:SOP_blocker_bug_process|blocker bug process]].<br />
<br />
For more on the Fedora development process, see [[Fedora Release Life Cycle]].<br />
<br />
{{admon/tip| <br />
If you are unsure whether your build is currently considered ''stable'' for a given release, you can check with {{command|koji latest-pkg fXX}} (where XX is the release).}}<br />
<br />
== Security updates ==<br />
<br />
There is an additional process that layers over the regular update process for bugs identified as security issues. If a bug is assigned to you that blocks a [[Security Tracking Bugs|security tracking bug]], you must follow that process in addition to this one.<br />
<br />
== New package submissions ==<br />
<br />
If you want to build a new package, but you aren't sure which releases to send it to:<br />
<br />
* New packages should always be built for Rawhide<br />
* New packages can be built for Branched and stable releases if adding them would provide value to users of those releases without significant risk of causing harm<br />
<br />
The submission process for new packages, after they have passed the [[Package_Review_Process]] and been [[Package_SCM_admin_requests|given an SCM repository]], is exactly the same as that for package updates.<br />
<br />
== Consider creating a package test plan ==<br />
<br />
If you [[QA:SOP_test_case_creation|create test cases]] for your package, and [[QA:SOP_package_test_plan_creation|categorize them appropriately]], they will be automatically linked in Bodhi, so that testers will have some guidance for planned update testing.<br />
<br />
[[Category:Package Maintainers]]</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Package_update_HOWTO&diff=514867Package update HOWTO2018-03-30T13:57:41Z<p>Puiterwijk: Accept nvrs in args</p>
<hr />
<div>This document shows how to submit an update for a package you maintain in Fedora. It assumes you already have a package in the Fedora repositories. It is not a guide to using the Fedora package source control system: see the [[Package maintenance guide]] for that.<br />
<br />
* For details of the policy on requirements for updates at various stages of the [[Fedora Release Life Cycle]], refer to [[Updates Policy]].<br />
<br />
== Overview ==<br />
<br />
This page is intended for new and existing package maintainers. Testers and regular users may be interested in the [[QA:Updates_Testing|updates-testing]] repository and the [[QA:Update_feedback_guidelines|update feedback guidelines]]. This page specifically covers the update submission process.<br />
<br />
There are two significantly different package update submission workflows in Fedora:<br />
<br />
* [[Releases/Rawhide|Rawhide]], and [[Releases/Branched|Branched]] up to the [[Updates Policy#Bodhi enabling|Bodhi enabling point]]<br />
* [[Releases/Branched|Branched]] releases after the Alpha change deadline, and stable releases<br />
<br />
The repository layouts differ somewhat for Rawhide, Branched and stable releases, but the update workflows split up as described above.<br />
<br />
== Rawhide and early Branched ==<br />
<br />
The package update workflow for Rawhide and Branched before the ''Bodhi enabling point'' is simple:<br />
<br />
# Build the package with {{command|fedpkg build}} (see the [[Package maintenance guide]] for more details)<br />
<br />
This is all you need to do. Your package will appear in the next daily compose of Rawhide or Branched and will be used in any image composes built from that tree.<br />
<br />
== Later Branched and stable releases ==<br />
<br />
At the [[Updates Policy#Bodhi enabling|Bodhi enabling point]], the [[Bodhi]] update feedback system is enabled by [[ReleaseEngineering|Release Engineering]] and builds submitted with {{command|fedpkg build}} are no longer automatically sent to any official [[Repositories|repository]]. The update workflow for releases of this type is:<br />
<br />
{{admon/tip|Fedora account name|{{command|fedpkg}} should be able to discover your [[Account_System|Fedora account system]] user name from the {{filename|~/.fedora.cert}} file set up by {{command|fedora-packager-setup}} when you first [[Join_the_package_collection_maintainers#Install_the_client_tools_.28Koji.29_and_set_up_your_certificate|configured your system for packaging]]. If this fails for any reason, you can specify it with {{command|--user (username)}}. For the {{command|bodhi}} command line tool, you may need to specify your Fedora user name with {{command|-u (username)}} if it differs from your system user name.}}<br />
<br />
# Build the package with {{command|fedpkg build}}<br />
# Submit an update for the package with {{command|fedpkg update}}, the [https://admin.fedoraproject.org/updates/ Bodhi web interface], or the [https://fedorahosted.org/bodhi/wiki/CLI Bodhi CLI tool]. This causes the package to be sent to the [[Repositories#updates-testing|''updates-testing'']] repository<br />
# Monitor the update's status and the feedback you receive via the web interface or the emails that are sent to you, and modify it with updated or additional builds if necessary<br />
# After the update meets the criteria in the [[Updates Policy]] and you are satisfied it should be released as a stable update, submit the update to ''[[Repositories#stable|stable]]'' with {{command|bodhi -R stable}} or the web interface<br />
<br />
{{admon/important|Updating inter-dependent packages|If a package you wish to update requires other package(s) to be rebuilt before it or they will work properly, you '''must''' submit the builds together as a multi-package update. See [[#multi|below]] for more details on this.}}<br />
<br />
=== Update attributes ===<br />
<br />
At the time you submit the update, you will be asked for several attributes. The type of the update should be fairly self-explanatory: either it fixes bugs, adds new features, or is a new package.<br />
<br />
If you are asked whether you want to send the update to ''updates-testing'' or ''stable'', this is a no-op: all updates now go through ''updates-testing''. It does not matter what you choose.<br />
<br />
There are several schools of thought on filling out the update description. Some would suggest you consider the target audience: for a stable release, in particular, many Fedora users will see this text, and many of them may not be particularly familiar with your package. Consider not simply describing literally the changes in the update, but explaining as if to an outsider why your are updating the package, what benefits it will bring to them (if any), and anything they may want to note in order to have a smooth update experience.<br />
<br />
If you associate one or more bug reports with your update, Bodhi will post comments into Bugzilla to alert those following the bug reports that an update is available. If you mark your update as fixing the bug(s), Bodhi will move the report(s) through the '''MODIFIED''', '''ON_QA''' and '''CLOSED ERRATA''' states of the [[BugZappers/BugStatusWorkFlow|bug workflow]] as your update reaches various points in the process. Using this mechanism can be very useful both for you and for users of your package.<br />
<br />
You may set a ''karma'' (feedback) level at which the update will automatically be submitted to ''stable''. This is optional. If you choose to use it, please carefully consider an appropriate feedback level. For a relatively obscure package which is quite stable, 1 or 2 may be an appropriate value. For a popular, sensitive and complex package such as {{package|firefox}} or the {{package|kernel}}, the default of 3 may be insufficient and a choice of 5 or even 10 may be appropriate.<br />
<br />
=== Who will receive your update, when? ===<br />
<br />
When a release is in Branched state, the ''updates-testing'' repository is enabled by default so most users will see the package, but only packages from the stable ''fedora'' repository are used in building milestone releases (Alpha, Beta and Final) and nightly images.<br />
<br />
Where a package goes when it is marked as ''stable'' differs between Branched and stable releases. In Branched releases, ''stable'' packages are pushed to the base ''fedora'' repository. In stable releases, ''stable'' packages are pushed to the ''updates'' repository. However, from the point of view of the packager, this is an insignificant implementation detail. For more details, see [[Repositories]].<br />
<br />
When a release is in stable state, the ''updates-testing'' repository is disabled by default, but [[QA]] team members and others run with it enabled in order to provide testing and Bodhi feedback. The main user population will see your update only when it passes Bodhi, is marked as ''stable'' and reaches the ''updates'' repository.<br />
<br />
{{anchor|multi}}<br />
=== Updating inter-dependent packages ===<br />
<br />
If an update you wish to submit would cause a dependency issue of any kind (a strict package dependency error, or simply another package failing to operate correctly) if updated alone, you must not submit the package as a single-package update. You must always collect all inter-dependent or related packages together into a single multi-package update, such that no user will face problems if they install all the packages in the update together.<br />
<br />
For example: if you maintain a package ''libfoo'' which the package ''bar'' depends on, and you need to update ''libfoo'', you should check that ''bar'' continues to function correctly with the updated version of ''libfoo''. If it does not, you must ensure the appropriate changes are made to ''bar'', and include the updated ''bar'' in your update along with the updated ''libfoo''.<br />
<br />
The ''fedpkg'' tool does not handle multi-package updates. You can add multiple packages to an update using the [https://admin.fedoraproject.org/updates/ Bodhi web application], or the {{command|bodhi}} command line tool. You can pass as many package names as you like to the {{command|bodhi --new}} to create a new multi-package update, or use {{command|bodhi --edit}} to edit an existing update.<br />
<br />
It is possible you will run into problems with permissions when trying to add builds of packages you do not have commit privileges for to an update, or trying to add a build for a package you do have privileges for to someone else's update. If you encounter a situation like this, you should contact the [[ReleaseEngineering|release engineering]] team or a proven packager for help.<br />
<br />
You may need a ''buildroot override'' to complete a multi-package update successfully. For instance in the case described above, you may need to rebuild ''bar'' against the new ''libfoo'' package and submit both packages together as a multi-package update. However, in the normal course of events, you would not be able to build another package against your new ''libfoo'' build until it reached the [[Repositories#stable|''stable'']] state. To resolve this dilemma, you can request a buildroot override, which causes the ''libfoo'' build to be included in the buildroot for a short time in order to get the ''bar'' package build done.<br />
<br />
You can request a buildroot override with bodhi: {{command|bodhi --buildroot-override<nowiki>=</nowiki>(name-version-release) --duration<nowiki>=</nowiki>2 --notes<nowiki>=</nowiki>"Useful details."}} This would submit a buildroot override with a duration of two days. Buildroot overrides are usually granted within 15-30 minutes of submission. If you submit an override request with the bodhi tool, it will suggest a command that will let you monitor when the package appears in the buildroot, so you can fire your dependent build at the appropriate time.<br />
<br />
You can also request buildroot overrides from the [https://admin.fedoraproject.org/updates/ Bodhi web application].<br />
<br />
The [[Bodhi/BuildRootOverrides|buildroot override instructions]] explain the buildroot override process in more detail.<br />
<br />
=== Handling feedback from automated tests ===<br />
<br />
Fedora's automated testing systems, [[Taskotron]] and [[OpenQA]], may run automated tests on your update. Several of the [[Taskotron/Tasks]] are documented. The openQA tests are functional tests of some critical [[Workstation]] and [[Server]] features.<br />
<br />
In the Bodhi web interface, updates have a ''Automated Tests'' tab which displays the results of all automated tests. Tests shown with a red background failed. The tests are not all 100% accurate, but they are fairly often correct. If you see a failure, it is a very good idea to click on the result (which will take you to a detailed log) and investigate the issue. If you are unsure what the test indicates, you can contact the [[QA]] team for help.<br />
<br />
==== Waive a result ====<br />
<br />
At present, a failure of the ''dist.rpmdeplint'', ''dist.abicheck'', or ''org.centos.prod.ci.pipeline.complete'' tests will prevent your update from being released. On the update's ''Details'' page in the Bodhi web interface, the '''Test Gating Status''' will be shown as ''N of N required tests failed''. If you are sure such a failure is a false one, you can 'waive' the result using the {{code|waiverdb-cli}} tool, from the {{package|waiverdb-cli}} package (there is [https://github.com/fedora-infra/bodhi/pull/2095 work pending] to be able to waiver more easily, directly from the Bodhi UI).<br />
<br />
You can submit a waiver for a failing result with {{pkg|waiverdb-cli}} specifying the {{code|subject}} and the {{code|testcase}}:<br />
<br />
waiverdb-cli -t YOUR_TESTCASE_HERE -s '{"item": "this-is-the-subject", "type": "also-this-is-part-of-the-subject"}' -p "fedora-26" -c "This is fine"<br />
<br />
Example:<br />
<br />
waiverdb-cli -t dist.rpmdeplint -s '{"item": "python-requests-1.2.3-1.fc26", "type": "koji_build"}' -p "fedora-26" -c "This is fine"<br />
<br />
You can also waive a failing result by result's id, which you can retrieve from resultsdb with curl. To do that, you'll need the {{code|testcase}} name and the {{code|nvr}}. For example:<br />
<br />
curl "https://taskotron.fedoraproject.org/resultsdb_api/api/v2.0/results?testcases=dist.python-versions&item=python-alembic-0.9.7-1.fc27" | jq ".data[0].id"<br />
<br />
This should print out the {{code|result_id}} of the failing result. You can then submit a waiver for this failing result with {{pkg|waiverdb-cli}}<br />
<br />
waiverdb-cli -p fedora-27 -r YOUR_ID_HERE -c "This is fine."<br />
<br />
Also, if you enabled automatic stable push at a karma threshold, this will be disabled if any automated test fails. If you have examined the result and you are sure it is a false one and there is no problem with the package, you may re-enable the automatic push mechanism or submit the package to ''stable'' manually once it meets the other requirements of the [[Updates Policy]].<br />
<br />
==== Waive the absence of a result ====<br />
<br />
Submitting a waiver using subject/testcase allows to waive the absence of a result (eg. the test never ran for some reason, so there is no result item).<br />
<br />
If which testcase you should be specified it is not clear/known, it is possible to run this python script, chainging it with the corrects parameter:<br />
<br />
#!/usr/bin/env python<br />
""" Ask a question of greenwave. """<br />
import pprint<br />
import requests<br />
import sys<br />
NVR_LIST = [] or sys.argv[1:] # Insert your NVRs here, or pass them via command line args<br />
for nvr in NVR_LIST:<br />
url = (<br />
'https://greenwave-web-greenwave.app.os.fedoraproject.org/'<br />
'api/v1.0/decision')<br />
payload = dict(<br />
#verbose=True,<br />
decision_context='bodhi_update_push_stable',<br />
product_version='fedora-27',<br />
subject=[{'item': nvr, 'type': 'koji_build'}],<br />
)<br />
response = requests.post(url, json=payload)<br />
print("-" * 40)<br />
print(nvr, response, response.status_code)<br />
data = response.json()<br />
print(pprint.pformat(data))<br />
<br />
The output will show that Greenwave is requiring a specific testcase to run, but it cannot find a result for it (neither pass nor failure). So now it is possible to submit a waiver with the specified testcase in the output and the subject already known.<br />
<br />
==== Troubleshooting ====<br />
<br />
If you run the {{code|waiverdb-cli}} tool and it gives you the following error:<br />
<br />
Error: The config option "resultsdb_api_url" is required<br />
<br />
Edit {{code|/etc/waiverdb/client.conf}} and add the following line:<br />
<br />
resultsdb_api_url=https://taskotron.fedoraproject.org/resultsdb_api/api/v2.0<br />
<br />
=== Branched milestone freezes ===<br />
<br />
For a short period before each milestone release, the stable [[Repositories#fedora|''fedora'']] repository is frozen. These periods are shown as the [[Milestone freezes]] (Beta Freeze, Final Freeze) on schedules. During these periods, builds will not be marked ''stable'' and pushed from [[Repositories#updates-testing|''updates-testing'']] to ''fedora'' even after being submitted manually or automatically. In the normal course of events, they will be pushed after the milestone release is approved at a [[Go_No_Go_Meeting]]. If you believe your update deserves to break a milestone freeze, a ''freeze exception'' may be granted through the [[QA:SOP_freeze_exception_bug_process|freeze exception process]]. Accepted release blocking bugs are granted the same status through the [[QA:SOP_blocker_bug_process|blocker bug process]].<br />
<br />
For more on the Fedora development process, see [[Fedora Release Life Cycle]].<br />
<br />
{{admon/tip| <br />
If you are unsure whether your build is currently considered ''stable'' for a given release, you can check with {{command|koji latest-pkg fXX}} (where XX is the release).}}<br />
<br />
== Security updates ==<br />
<br />
There is an additional process that layers over the regular update process for bugs identified as security issues. If a bug is assigned to you that blocks a [[Security Tracking Bugs|security tracking bug]], you must follow that process in addition to this one.<br />
<br />
== New package submissions ==<br />
<br />
If you want to build a new package, but you aren't sure which releases to send it to:<br />
<br />
* New packages should always be built for Rawhide<br />
* New packages can be built for Branched and stable releases if adding them would provide value to users of those releases without significant risk of causing harm<br />
<br />
The submission process for new packages, after they have passed the [[Package_Review_Process]] and been [[Package_SCM_admin_requests|given an SCM repository]], is exactly the same as that for package updates.<br />
<br />
== Consider creating a package test plan ==<br />
<br />
If you [[QA:SOP_test_case_creation|create test cases]] for your package, and [[QA:SOP_package_test_plan_creation|categorize them appropriately]], they will be automatically linked in Bodhi, so that testers will have some guidance for planned update testing.<br />
<br />
[[Category:Package Maintainers]]</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Package_update_HOWTO&diff=514866Package update HOWTO2018-03-30T13:54:14Z<p>Puiterwijk: Remove extra spaces</p>
<hr />
<div>This document shows how to submit an update for a package you maintain in Fedora. It assumes you already have a package in the Fedora repositories. It is not a guide to using the Fedora package source control system: see the [[Package maintenance guide]] for that.<br />
<br />
* For details of the policy on requirements for updates at various stages of the [[Fedora Release Life Cycle]], refer to [[Updates Policy]].<br />
<br />
== Overview ==<br />
<br />
This page is intended for new and existing package maintainers. Testers and regular users may be interested in the [[QA:Updates_Testing|updates-testing]] repository and the [[QA:Update_feedback_guidelines|update feedback guidelines]]. This page specifically covers the update submission process.<br />
<br />
There are two significantly different package update submission workflows in Fedora:<br />
<br />
* [[Releases/Rawhide|Rawhide]], and [[Releases/Branched|Branched]] up to the [[Updates Policy#Bodhi enabling|Bodhi enabling point]]<br />
* [[Releases/Branched|Branched]] releases after the Alpha change deadline, and stable releases<br />
<br />
The repository layouts differ somewhat for Rawhide, Branched and stable releases, but the update workflows split up as described above.<br />
<br />
== Rawhide and early Branched ==<br />
<br />
The package update workflow for Rawhide and Branched before the ''Bodhi enabling point'' is simple:<br />
<br />
# Build the package with {{command|fedpkg build}} (see the [[Package maintenance guide]] for more details)<br />
<br />
This is all you need to do. Your package will appear in the next daily compose of Rawhide or Branched and will be used in any image composes built from that tree.<br />
<br />
== Later Branched and stable releases ==<br />
<br />
At the [[Updates Policy#Bodhi enabling|Bodhi enabling point]], the [[Bodhi]] update feedback system is enabled by [[ReleaseEngineering|Release Engineering]] and builds submitted with {{command|fedpkg build}} are no longer automatically sent to any official [[Repositories|repository]]. The update workflow for releases of this type is:<br />
<br />
{{admon/tip|Fedora account name|{{command|fedpkg}} should be able to discover your [[Account_System|Fedora account system]] user name from the {{filename|~/.fedora.cert}} file set up by {{command|fedora-packager-setup}} when you first [[Join_the_package_collection_maintainers#Install_the_client_tools_.28Koji.29_and_set_up_your_certificate|configured your system for packaging]]. If this fails for any reason, you can specify it with {{command|--user (username)}}. For the {{command|bodhi}} command line tool, you may need to specify your Fedora user name with {{command|-u (username)}} if it differs from your system user name.}}<br />
<br />
# Build the package with {{command|fedpkg build}}<br />
# Submit an update for the package with {{command|fedpkg update}}, the [https://admin.fedoraproject.org/updates/ Bodhi web interface], or the [https://fedorahosted.org/bodhi/wiki/CLI Bodhi CLI tool]. This causes the package to be sent to the [[Repositories#updates-testing|''updates-testing'']] repository<br />
# Monitor the update's status and the feedback you receive via the web interface or the emails that are sent to you, and modify it with updated or additional builds if necessary<br />
# After the update meets the criteria in the [[Updates Policy]] and you are satisfied it should be released as a stable update, submit the update to ''[[Repositories#stable|stable]]'' with {{command|bodhi -R stable}} or the web interface<br />
<br />
{{admon/important|Updating inter-dependent packages|If a package you wish to update requires other package(s) to be rebuilt before it or they will work properly, you '''must''' submit the builds together as a multi-package update. See [[#multi|below]] for more details on this.}}<br />
<br />
=== Update attributes ===<br />
<br />
At the time you submit the update, you will be asked for several attributes. The type of the update should be fairly self-explanatory: either it fixes bugs, adds new features, or is a new package.<br />
<br />
If you are asked whether you want to send the update to ''updates-testing'' or ''stable'', this is a no-op: all updates now go through ''updates-testing''. It does not matter what you choose.<br />
<br />
There are several schools of thought on filling out the update description. Some would suggest you consider the target audience: for a stable release, in particular, many Fedora users will see this text, and many of them may not be particularly familiar with your package. Consider not simply describing literally the changes in the update, but explaining as if to an outsider why your are updating the package, what benefits it will bring to them (if any), and anything they may want to note in order to have a smooth update experience.<br />
<br />
If you associate one or more bug reports with your update, Bodhi will post comments into Bugzilla to alert those following the bug reports that an update is available. If you mark your update as fixing the bug(s), Bodhi will move the report(s) through the '''MODIFIED''', '''ON_QA''' and '''CLOSED ERRATA''' states of the [[BugZappers/BugStatusWorkFlow|bug workflow]] as your update reaches various points in the process. Using this mechanism can be very useful both for you and for users of your package.<br />
<br />
You may set a ''karma'' (feedback) level at which the update will automatically be submitted to ''stable''. This is optional. If you choose to use it, please carefully consider an appropriate feedback level. For a relatively obscure package which is quite stable, 1 or 2 may be an appropriate value. For a popular, sensitive and complex package such as {{package|firefox}} or the {{package|kernel}}, the default of 3 may be insufficient and a choice of 5 or even 10 may be appropriate.<br />
<br />
=== Who will receive your update, when? ===<br />
<br />
When a release is in Branched state, the ''updates-testing'' repository is enabled by default so most users will see the package, but only packages from the stable ''fedora'' repository are used in building milestone releases (Alpha, Beta and Final) and nightly images.<br />
<br />
Where a package goes when it is marked as ''stable'' differs between Branched and stable releases. In Branched releases, ''stable'' packages are pushed to the base ''fedora'' repository. In stable releases, ''stable'' packages are pushed to the ''updates'' repository. However, from the point of view of the packager, this is an insignificant implementation detail. For more details, see [[Repositories]].<br />
<br />
When a release is in stable state, the ''updates-testing'' repository is disabled by default, but [[QA]] team members and others run with it enabled in order to provide testing and Bodhi feedback. The main user population will see your update only when it passes Bodhi, is marked as ''stable'' and reaches the ''updates'' repository.<br />
<br />
{{anchor|multi}}<br />
=== Updating inter-dependent packages ===<br />
<br />
If an update you wish to submit would cause a dependency issue of any kind (a strict package dependency error, or simply another package failing to operate correctly) if updated alone, you must not submit the package as a single-package update. You must always collect all inter-dependent or related packages together into a single multi-package update, such that no user will face problems if they install all the packages in the update together.<br />
<br />
For example: if you maintain a package ''libfoo'' which the package ''bar'' depends on, and you need to update ''libfoo'', you should check that ''bar'' continues to function correctly with the updated version of ''libfoo''. If it does not, you must ensure the appropriate changes are made to ''bar'', and include the updated ''bar'' in your update along with the updated ''libfoo''.<br />
<br />
The ''fedpkg'' tool does not handle multi-package updates. You can add multiple packages to an update using the [https://admin.fedoraproject.org/updates/ Bodhi web application], or the {{command|bodhi}} command line tool. You can pass as many package names as you like to the {{command|bodhi --new}} to create a new multi-package update, or use {{command|bodhi --edit}} to edit an existing update.<br />
<br />
It is possible you will run into problems with permissions when trying to add builds of packages you do not have commit privileges for to an update, or trying to add a build for a package you do have privileges for to someone else's update. If you encounter a situation like this, you should contact the [[ReleaseEngineering|release engineering]] team or a proven packager for help.<br />
<br />
You may need a ''buildroot override'' to complete a multi-package update successfully. For instance in the case described above, you may need to rebuild ''bar'' against the new ''libfoo'' package and submit both packages together as a multi-package update. However, in the normal course of events, you would not be able to build another package against your new ''libfoo'' build until it reached the [[Repositories#stable|''stable'']] state. To resolve this dilemma, you can request a buildroot override, which causes the ''libfoo'' build to be included in the buildroot for a short time in order to get the ''bar'' package build done.<br />
<br />
You can request a buildroot override with bodhi: {{command|bodhi --buildroot-override<nowiki>=</nowiki>(name-version-release) --duration<nowiki>=</nowiki>2 --notes<nowiki>=</nowiki>"Useful details."}} This would submit a buildroot override with a duration of two days. Buildroot overrides are usually granted within 15-30 minutes of submission. If you submit an override request with the bodhi tool, it will suggest a command that will let you monitor when the package appears in the buildroot, so you can fire your dependent build at the appropriate time.<br />
<br />
You can also request buildroot overrides from the [https://admin.fedoraproject.org/updates/ Bodhi web application].<br />
<br />
The [[Bodhi/BuildRootOverrides|buildroot override instructions]] explain the buildroot override process in more detail.<br />
<br />
=== Handling feedback from automated tests ===<br />
<br />
Fedora's automated testing systems, [[Taskotron]] and [[OpenQA]], may run automated tests on your update. Several of the [[Taskotron/Tasks]] are documented. The openQA tests are functional tests of some critical [[Workstation]] and [[Server]] features.<br />
<br />
In the Bodhi web interface, updates have a ''Automated Tests'' tab which displays the results of all automated tests. Tests shown with a red background failed. The tests are not all 100% accurate, but they are fairly often correct. If you see a failure, it is a very good idea to click on the result (which will take you to a detailed log) and investigate the issue. If you are unsure what the test indicates, you can contact the [[QA]] team for help.<br />
<br />
==== Waive a result ====<br />
<br />
At present, a failure of the ''dist.rpmdeplint'', ''dist.abicheck'', or ''org.centos.prod.ci.pipeline.complete'' tests will prevent your update from being released. On the update's ''Details'' page in the Bodhi web interface, the '''Test Gating Status''' will be shown as ''N of N required tests failed''. If you are sure such a failure is a false one, you can 'waive' the result using the {{code|waiverdb-cli}} tool, from the {{package|waiverdb-cli}} package (there is [https://github.com/fedora-infra/bodhi/pull/2095 work pending] to be able to waiver more easily, directly from the Bodhi UI).<br />
<br />
You can submit a waiver for a failing result with {{pkg|waiverdb-cli}} specifying the {{code|subject}} and the {{code|testcase}}:<br />
<br />
waiverdb-cli -t YOUR_TESTCASE_HERE -s '{"item": "this-is-the-subject", "type": "also-this-is-part-of-the-subject"}' -p "fedora-26" -c "This is fine"<br />
<br />
Example:<br />
<br />
waiverdb-cli -t dist.rpmdeplint -s '{"item": "python-requests-1.2.3-1.fc26", "type": "koji_build"}' -p "fedora-26" -c "This is fine"<br />
<br />
You can also waive a failing result by result's id, which you can retrieve from resultsdb with curl. To do that, you'll need the {{code|testcase}} name and the {{code|nvr}}. For example:<br />
<br />
curl "https://taskotron.fedoraproject.org/resultsdb_api/api/v2.0/results?testcases=dist.python-versions&item=python-alembic-0.9.7-1.fc27" | jq ".data[0].id"<br />
<br />
This should print out the {{code|result_id}} of the failing result. You can then submit a waiver for this failing result with {{pkg|waiverdb-cli}}<br />
<br />
waiverdb-cli -p fedora-27 -r YOUR_ID_HERE -c "This is fine."<br />
<br />
Also, if you enabled automatic stable push at a karma threshold, this will be disabled if any automated test fails. If you have examined the result and you are sure it is a false one and there is no problem with the package, you may re-enable the automatic push mechanism or submit the package to ''stable'' manually once it meets the other requirements of the [[Updates Policy]].<br />
<br />
==== Waive the absence of a result ====<br />
<br />
Submitting a waiver using subject/testcase allows to waive the absence of a result (eg. the test never ran for some reason, so there is no result item).<br />
<br />
If which testcase you should be specified it is not clear/known, it is possible to run this python script, chainging it with the corrects parameter:<br />
<br />
#!/usr/bin/env python<br />
""" Ask a question of greenwave. """<br />
import pprint<br />
import requests<br />
NVR_LIST = ['put', 'your', 'nvrs', 'here']<br />
for nvr in NVR_LIST:<br />
url = (<br />
'https://greenwave-web-greenwave.app.os.fedoraproject.org/'<br />
'api/v1.0/decision')<br />
payload = dict(<br />
#verbose=True,<br />
decision_context='bodhi_update_push_stable',<br />
product_version='fedora-27',<br />
subject=[{'item': nvr, 'type': 'koji_build'}],<br />
)<br />
response = requests.post(url, json=payload)<br />
print("-" * 40)<br />
print(nvr, response, response.status_code)<br />
data = response.json()<br />
print(pprint.pformat(data))<br />
<br />
The output will show that Greenwave is requiring a specific testcase to run, but it cannot find a result for it (neither pass nor failure). So now it is possible to submit a waiver with the specified testcase in the output and the subject already known.<br />
<br />
==== Troubleshooting ====<br />
<br />
If you run the {{code|waiverdb-cli}} tool and it gives you the following error:<br />
<br />
Error: The config option "resultsdb_api_url" is required<br />
<br />
Edit {{code|/etc/waiverdb/client.conf}} and add the following line:<br />
<br />
resultsdb_api_url=https://taskotron.fedoraproject.org/resultsdb_api/api/v2.0<br />
<br />
=== Branched milestone freezes ===<br />
<br />
For a short period before each milestone release, the stable [[Repositories#fedora|''fedora'']] repository is frozen. These periods are shown as the [[Milestone freezes]] (Beta Freeze, Final Freeze) on schedules. During these periods, builds will not be marked ''stable'' and pushed from [[Repositories#updates-testing|''updates-testing'']] to ''fedora'' even after being submitted manually or automatically. In the normal course of events, they will be pushed after the milestone release is approved at a [[Go_No_Go_Meeting]]. If you believe your update deserves to break a milestone freeze, a ''freeze exception'' may be granted through the [[QA:SOP_freeze_exception_bug_process|freeze exception process]]. Accepted release blocking bugs are granted the same status through the [[QA:SOP_blocker_bug_process|blocker bug process]].<br />
<br />
For more on the Fedora development process, see [[Fedora Release Life Cycle]].<br />
<br />
{{admon/tip| <br />
If you are unsure whether your build is currently considered ''stable'' for a given release, you can check with {{command|koji latest-pkg fXX}} (where XX is the release).}}<br />
<br />
== Security updates ==<br />
<br />
There is an additional process that layers over the regular update process for bugs identified as security issues. If a bug is assigned to you that blocks a [[Security Tracking Bugs|security tracking bug]], you must follow that process in addition to this one.<br />
<br />
== New package submissions ==<br />
<br />
If you want to build a new package, but you aren't sure which releases to send it to:<br />
<br />
* New packages should always be built for Rawhide<br />
* New packages can be built for Branched and stable releases if adding them would provide value to users of those releases without significant risk of causing harm<br />
<br />
The submission process for new packages, after they have passed the [[Package_Review_Process]] and been [[Package_SCM_admin_requests|given an SCM repository]], is exactly the same as that for package updates.<br />
<br />
== Consider creating a package test plan ==<br />
<br />
If you [[QA:SOP_test_case_creation|create test cases]] for your package, and [[QA:SOP_package_test_plan_creation|categorize them appropriately]], they will be automatically linked in Bodhi, so that testers will have some guidance for planned update testing.<br />
<br />
[[Category:Package Maintainers]]</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Package_update_HOWTO&diff=514512Package update HOWTO2018-03-29T00:24:42Z<p>Puiterwijk: Unverified TLS is not acceptable</p>
<hr />
<div>This document shows how to submit an update for a package you maintain in Fedora. It assumes you already have a package in the Fedora repositories. It is not a guide to using the Fedora package source control system: see the [[Package maintenance guide]] for that.<br />
<br />
* For details of the policy on requirements for updates at various stages of the [[Fedora Release Life Cycle]], refer to [[Updates Policy]].<br />
<br />
== Overview ==<br />
<br />
This page is intended for new and existing package maintainers. Testers and regular users may be interested in the [[QA:Updates_Testing|updates-testing]] repository and the [[QA:Update_feedback_guidelines|update feedback guidelines]]. This page specifically covers the update submission process.<br />
<br />
There are two significantly different package update submission workflows in Fedora:<br />
<br />
* [[Releases/Rawhide|Rawhide]], and [[Releases/Branched|Branched]] up to the [[Updates Policy#Bodhi enabling|Bodhi enabling point]]<br />
* [[Releases/Branched|Branched]] releases after the Alpha change deadline, and stable releases<br />
<br />
The repository layouts differ somewhat for Rawhide, Branched and stable releases, but the update workflows split up as described above.<br />
<br />
== Rawhide and early Branched ==<br />
<br />
The package update workflow for Rawhide and Branched before the ''Bodhi enabling point'' is simple:<br />
<br />
# Build the package with {{command|fedpkg build}} (see the [[Package maintenance guide]] for more details)<br />
<br />
This is all you need to do. Your package will appear in the next daily compose of Rawhide or Branched and will be used in any image composes built from that tree.<br />
<br />
== Later Branched and stable releases ==<br />
<br />
At the [[Updates Policy#Bodhi enabling|Bodhi enabling point]], the [[Bodhi]] update feedback system is enabled by [[ReleaseEngineering|Release Engineering]] and builds submitted with {{command|fedpkg build}} are no longer automatically sent to any official [[Repositories|repository]]. The update workflow for releases of this type is:<br />
<br />
{{admon/tip|Fedora account name|{{command|fedpkg}} should be able to discover your [[Account_System|Fedora account system]] user name from the {{filename|~/.fedora.cert}} file set up by {{command|fedora-packager-setup}} when you first [[Join_the_package_collection_maintainers#Install_the_client_tools_.28Koji.29_and_set_up_your_certificate|configured your system for packaging]]. If this fails for any reason, you can specify it with {{command|--user (username)}}. For the {{command|bodhi}} command line tool, you may need to specify your Fedora user name with {{command|-u (username)}} if it differs from your system user name.}}<br />
<br />
# Build the package with {{command|fedpkg build}}<br />
# Submit an update for the package with {{command|fedpkg update}}, the [https://admin.fedoraproject.org/updates/ Bodhi web interface], or the [https://fedorahosted.org/bodhi/wiki/CLI Bodhi CLI tool]. This causes the package to be sent to the [[Repositories#updates-testing|''updates-testing'']] repository<br />
# Monitor the update's status and the feedback you receive via the web interface or the emails that are sent to you, and modify it with updated or additional builds if necessary<br />
# After the update meets the criteria in the [[Updates Policy]] and you are satisfied it should be released as a stable update, submit the update to ''[[Repositories#stable|stable]]'' with {{command|bodhi -R stable}} or the web interface<br />
<br />
{{admon/important|Updating inter-dependent packages|If a package you wish to update requires other package(s) to be rebuilt before it or they will work properly, you '''must''' submit the builds together as a multi-package update. See [[#multi|below]] for more details on this.}}<br />
<br />
=== Update attributes ===<br />
<br />
At the time you submit the update, you will be asked for several attributes. The type of the update should be fairly self-explanatory: either it fixes bugs, adds new features, or is a new package.<br />
<br />
If you are asked whether you want to send the update to ''updates-testing'' or ''stable'', this is a no-op: all updates now go through ''updates-testing''. It does not matter what you choose.<br />
<br />
There are several schools of thought on filling out the update description. Some would suggest you consider the target audience: for a stable release, in particular, many Fedora users will see this text, and many of them may not be particularly familiar with your package. Consider not simply describing literally the changes in the update, but explaining as if to an outsider why your are updating the package, what benefits it will bring to them (if any), and anything they may want to note in order to have a smooth update experience.<br />
<br />
If you associate one or more bug reports with your update, Bodhi will post comments into Bugzilla to alert those following the bug reports that an update is available. If you mark your update as fixing the bug(s), Bodhi will move the report(s) through the '''MODIFIED''', '''ON_QA''' and '''CLOSED ERRATA''' states of the [[BugZappers/BugStatusWorkFlow|bug workflow]] as your update reaches various points in the process. Using this mechanism can be very useful both for you and for users of your package.<br />
<br />
You may set a ''karma'' (feedback) level at which the update will automatically be submitted to ''stable''. This is optional. If you choose to use it, please carefully consider an appropriate feedback level. For a relatively obscure package which is quite stable, 1 or 2 may be an appropriate value. For a popular, sensitive and complex package such as {{package|firefox}} or the {{package|kernel}}, the default of 3 may be insufficient and a choice of 5 or even 10 may be appropriate.<br />
<br />
=== Who will receive your update, when? ===<br />
<br />
When a release is in Branched state, the ''updates-testing'' repository is enabled by default so most users will see the package, but only packages from the stable ''fedora'' repository are used in building milestone releases (Alpha, Beta and Final) and nightly images.<br />
<br />
Where a package goes when it is marked as ''stable'' differs between Branched and stable releases. In Branched releases, ''stable'' packages are pushed to the base ''fedora'' repository. In stable releases, ''stable'' packages are pushed to the ''updates'' repository. However, from the point of view of the packager, this is an insignificant implementation detail. For more details, see [[Repositories]].<br />
<br />
When a release is in stable state, the ''updates-testing'' repository is disabled by default, but [[QA]] team members and others run with it enabled in order to provide testing and Bodhi feedback. The main user population will see your update only when it passes Bodhi, is marked as ''stable'' and reaches the ''updates'' repository.<br />
<br />
{{anchor|multi}}<br />
=== Updating inter-dependent packages ===<br />
<br />
If an update you wish to submit would cause a dependency issue of any kind (a strict package dependency error, or simply another package failing to operate correctly) if updated alone, you must not submit the package as a single-package update. You must always collect all inter-dependent or related packages together into a single multi-package update, such that no user will face problems if they install all the packages in the update together.<br />
<br />
For example: if you maintain a package ''libfoo'' which the package ''bar'' depends on, and you need to update ''libfoo'', you should check that ''bar'' continues to function correctly with the updated version of ''libfoo''. If it does not, you must ensure the appropriate changes are made to ''bar'', and include the updated ''bar'' in your update along with the updated ''libfoo''.<br />
<br />
The ''fedpkg'' tool does not handle multi-package updates. You can add multiple packages to an update using the [https://admin.fedoraproject.org/updates/ Bodhi web application], or the {{command|bodhi}} command line tool. You can pass as many package names as you like to the {{command|bodhi --new}} to create a new multi-package update, or use {{command|bodhi --edit}} to edit an existing update.<br />
<br />
It is possible you will run into problems with permissions when trying to add builds of packages you do not have commit privileges for to an update, or trying to add a build for a package you do have privileges for to someone else's update. If you encounter a situation like this, you should contact the [[ReleaseEngineering|release engineering]] team or a proven packager for help.<br />
<br />
You may need a ''buildroot override'' to complete a multi-package update successfully. For instance in the case described above, you may need to rebuild ''bar'' against the new ''libfoo'' package and submit both packages together as a multi-package update. However, in the normal course of events, you would not be able to build another package against your new ''libfoo'' build until it reached the [[Repositories#stable|''stable'']] state. To resolve this dilemma, you can request a buildroot override, which causes the ''libfoo'' build to be included in the buildroot for a short time in order to get the ''bar'' package build done.<br />
<br />
You can request a buildroot override with bodhi: {{command|bodhi --buildroot-override<nowiki>=</nowiki>(name-version-release) --duration<nowiki>=</nowiki>2 --notes<nowiki>=</nowiki>"Useful details."}} This would submit a buildroot override with a duration of two days. Buildroot overrides are usually granted within 15-30 minutes of submission. If you submit an override request with the bodhi tool, it will suggest a command that will let you monitor when the package appears in the buildroot, so you can fire your dependent build at the appropriate time.<br />
<br />
You can also request buildroot overrides from the [https://admin.fedoraproject.org/updates/ Bodhi web application].<br />
<br />
The [[Bodhi/BuildRootOverrides|buildroot override instructions]] explain the buildroot override process in more detail.<br />
<br />
=== Handling feedback from automated tests ===<br />
<br />
Fedora's automated testing systems, [[Taskotron]] and [[OpenQA]], may run automated tests on your update. Several of the [[Taskotron/Tasks]] are documented. The openQA tests are functional tests of some critical [[Workstation]] and [[Server]] features.<br />
<br />
In the Bodhi web interface, updates have a ''Automated Tests'' tab which displays the results of all automated tests. Tests shown with a red background failed. The tests are not all 100% accurate, but they are fairly often correct. If you see a failure, it is a very good idea to click on the result (which will take you to a detailed log) and investigate the issue. If you are unsure what the test indicates, you can contact the [[QA]] team for help.<br />
<br />
==== Waive a result ====<br />
<br />
At present, a failure of the ''dist.rpmdeplint'', ''dist.abicheck'', or ''org.centos.prod.ci.pipeline.complete'' tests will prevent your update from being released. On the update's ''Details'' page in the Bodhi web interface, the '''Test Gating Status''' will be shown as ''N of N required tests failed''. If you are sure such a failure is a false one, you can 'waive' the result using the {{code|waiverdb-cli}} tool, from the {{package|waiverdb-cli}} package (there is [https://github.com/fedora-infra/bodhi/pull/2095 work pending] to be able to waiver more easily, directly from the Bodhi UI).<br />
<br />
You can submit a waiver for a failing result with {{pkg|waiverdb-cli}} specifying the {{code|subject}} and the {{code|testcase}}:<br />
<br />
waiverdb-cli -t YOUR_TESTCASE_HERE -s '{"item": "this-is-the-subject", "type": "also-this-is-part-of-the-subject"}' -p "fedora-26" -c "This is fine"<br />
<br />
Example:<br />
<br />
waiverdb-cli -t dist.rpmdeplint -s '{"item": "python-requests-1.2.3-1.fc26", "type": "koji_build"}' -p "fedora-26" -c "This is fine"<br />
<br />
You can also waive a failing result by result's id, which you can retrieve from resultsdb with curl. To do that, you'll need the {{code|testcase}} name and the {{code|nvr}}. For example:<br />
<br />
curl "https://taskotron.fedoraproject.org/resultsdb_api/api/v2.0/results?testcases=dist.python-versions&item=python-alembic-0.9.7-1.fc27" | jq ".data[0].id"<br />
<br />
This should print out the {{code|result_id}} of the failing result. You can then submit a waiver for this failing result with {{pkg|waiverdb-cli}}<br />
<br />
waiverdb-cli -p fedora-27 -r YOUR_ID_HERE -c "This is fine."<br />
<br />
Also, if you enabled automatic stable push at a karma threshold, this will be disabled if any automated test fails. If you have examined the result and you are sure it is a false one and there is no problem with the package, you may re-enable the automatic push mechanism or submit the package to ''stable'' manually once it meets the other requirements of the [[Updates Policy]].<br />
<br />
==== Waive the absence of a result ====<br />
<br />
Submitting a waiver using subject/testcase allows to waive the absence of a result (eg. the test never ran for some reason, so there is no result item).<br />
<br />
If which testcase you should be specified it is not clear/known, it is possible to run this python script, chainging it with the corrects parameter:<br />
<br />
#!/usr/bin/env python<br />
""" Ask a question of greenwave. """<br />
import pprint<br />
import requests<br />
NVR_LIST = ['put', 'your', 'nvrs', 'here']<br />
for nvr in NVR_LIST:<br />
url = (<br />
'https://greenwave-web-greenwave.app.os.fedoraproject.org/'<br />
'api/v1.0/decision')<br />
payload = dict(<br />
#verbose=True,<br />
decision_context='bodhi_update_push_stable',<br />
product_version='fedora-27',<br />
subject=[{'item': nvr, 'type': 'koji_build'}],<br />
)<br />
response = requests.post(url, json=payload)<br />
print("-" * 40)<br />
print(nvr, response, response.status_code)<br />
data = response.json()<br />
print(pprint.pformat(data))<br />
<br />
The output will show that Greenwave is requiring a specific testcase to run, but it cannot find a result for it (neither pass nor failure). So now it is possible to submit a waiver with the specified testcase in the output and the subject already known.<br />
<br />
==== Troubleshooting ====<br />
<br />
If you run the {{code|waiverdb-cli}} tool and it gives you the following error:<br />
<br />
Error: The config option "resultsdb_api_url" is required<br />
<br />
Edit {{code|/etc/waiverdb/client.conf}} and add the following line:<br />
<br />
resultsdb_api_url=https://taskotron.fedoraproject.org/resultsdb_api/api/v2.0<br />
<br />
=== Branched milestone freezes ===<br />
<br />
For a short period before each milestone release, the stable [[Repositories#fedora|''fedora'']] repository is frozen. These periods are shown as the [[Milestone freezes]] (Beta Freeze, Final Freeze) on schedules. During these periods, builds will not be marked ''stable'' and pushed from [[Repositories#updates-testing|''updates-testing'']] to ''fedora'' even after being submitted manually or automatically. In the normal course of events, they will be pushed after the milestone release is approved at a [[Go_No_Go_Meeting]]. If you believe your update deserves to break a milestone freeze, a ''freeze exception'' may be granted through the [[QA:SOP_freeze_exception_bug_process|freeze exception process]]. Accepted release blocking bugs are granted the same status through the [[QA:SOP_blocker_bug_process|blocker bug process]].<br />
<br />
For more on the Fedora development process, see [[Fedora Release Life Cycle]].<br />
<br />
{{admon/tip| <br />
If you are unsure whether your build is currently considered ''stable'' for a given release, you can check with {{command|koji latest-pkg fXX}} (where XX is the release).}}<br />
<br />
== Security updates ==<br />
<br />
There is an additional process that layers over the regular update process for bugs identified as security issues. If a bug is assigned to you that blocks a [[Security Tracking Bugs|security tracking bug]], you must follow that process in addition to this one.<br />
<br />
== New package submissions ==<br />
<br />
If you want to build a new package, but you aren't sure which releases to send it to:<br />
<br />
* New packages should always be built for Rawhide<br />
* New packages can be built for Branched and stable releases if adding them would provide value to users of those releases without significant risk of causing harm<br />
<br />
The submission process for new packages, after they have passed the [[Package_Review_Process]] and been [[Package_SCM_admin_requests|given an SCM repository]], is exactly the same as that for package updates.<br />
<br />
== Consider creating a package test plan ==<br />
<br />
If you [[QA:SOP_test_case_creation|create test cases]] for your package, and [[QA:SOP_package_test_plan_creation|categorize them appropriately]], they will be automatically linked in Bodhi, so that testers will have some guidance for planned update testing.<br />
<br />
[[Category:Package Maintainers]]</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Infrastructure_Hackathon_2018&diff=513370Infrastructure Hackathon 20182018-03-19T23:21:56Z<p>Puiterwijk: Add puiterwijk arrival/departure info</p>
<hr />
<div>This is the main page for an [[infrastructure]] hackathon in spring 2018. This hackathon is intended to help the team leap ahead for several critical Fedora and CentOS initiatives.<br />
<br />
== Working Session Notes ==<br />
<br />
Coming soon -- winter 2017/2018.<br />
<br />
=== Output and outcomes ===<br />
<br />
This section will record output blogs following the event.<br />
<br />
== Purpose ==<br />
Our purpose is to complete the following '''primary''' goals:<br />
<br />
=== Day 0 (Sunday) ===<br />
<br />
* Travel to hackathon<br />
<br />
=== Day 1 (Monday) ===<br />
<br />
* Clean up Docs, workflows and scripts for new services<br />
<br />
=== Day 2 (Tuesday) ===<br />
<br />
* ELK proof of concept <br />
* Rawhide gating and CI<br />
<br />
=== Day 3 (Wednesday) ===<br />
<br />
* AWX setup in Fedora Infrastructure<br />
* More Rawhide Gating and CI<br />
<br />
=== Day 4 (Thursday) ===<br />
<br />
* Move some apps to OpenShift (extra goal)<br />
* Bodhi hackfest (extra goal)<br />
* Pagure hackfest (extra goal)<br />
* Jenkins jobs refactor (extra goal)<br />
<br />
=== Day 5 (Friday) ===<br />
<br />
* Knowledge transfer and finish up<br />
<br />
== Detailed Work Items & Final Attendees ==<br />
<br />
=== Deliverables ===<br />
<br />
{| class="wikitable"<br />
! Deliverables: ((TOPIC 1)) !! Task Owner !! Done <br />
|-<br />
| Better docs, workflows and scripts for package maintainers || || (check here when done)<br />
|-<br />
! Deliverables: ((TOPIC 2)) !! Task Owner !! Done <br />
|-<br />
| Working AWX instance in Fedora Infrastructure || || (check here when done)<br />
|-<br />
! Deliverables: ((TOPIC 2)) !! Task Owner !! Done <br />
|-<br />
| Working ELK search engine proof of concept || || (check here when done)<br />
|-<br />
! Deliverables: ((TOPIC 2)) !! Task Owner !! Done <br />
|-<br />
| Rawhide gating of some kind || || (check here when done)<br />
|-<br />
! Deliverables: ((TOPIC 2)) !! Task Owner !! Done <br />
|-<br />
| More apps in openshift || || (check here when done) <br />
|-<br />
! Deliverables: ((TOPIC 2)) !! Task Owner !! Done <br />
|-<br />
| jenkins jobs refactored || || (check here when done)<br />
|-<br />
|}<br />
<br />
=== Follow-up tickets ===<br />
<br />
{| class="wikitable"<br />
! Follow-up: !! Ticket <br />
|-<br />
| (Describe item that still needs to be completed) || (link to ticket)<br />
|}<br />
<br />
=== Attendees and Travel Details ===<br />
{{admon/note | Travel details | Refer to [[Infrastructure Hackathon 2018/Travel]] for itineraries and costs.}}<br />
{| class="wikitable"<br />
! Contributor !! Arrival !! Departure !! Roommate !! Notes (airfare costs) !! Paid/expensed?<br />
|-<br />
| [[User:Smooge|Stephen Smoogen]] || Apr 8 15:03 Amtrak || Apr 13 12:20 Amtrak || [[User:Codeblock|Ricky Elrod]] || $100 (train) || <br />
|-<br />
| [[User:Puiterwijk|Patrick Uiterwijk]] || 2018-04-08 15:35 IAD - EI0119 || 2018-04-13 17:15 IAD - EI0118 || [[User:Kevin|Kevin Fenzi]] || $1000 (handled from Platform dept) || yes<br />
|-<br />
| [[User:Codeblock|Ricky Elrod]] || Apr 8, 20:57, IAD, UA6031 || Apr 13, 12:50, IAD, UA4995 || [[User:Smooge|Stephen Smoogen]] || $250 (handled from Platform dept) || yes<br />
|-<br />
| [[User:Dustymabe|Dusty Mabe]] || Apr 8 15:03 Amtrak || Apr 13 12:20 Amtrak || || $100 (train) || <br />
|-<br />
| [[User:Rbarlow|Randy Barlow]] || Apr 8 15:03 Amtrak || Apr 13 12:20 Amtrak || [[User:Pingou|Pierre-Yves Chibon]] || $100 (train) || <br />
|-<br />
| [[User:Kevin|Kevin Fenzi]] || Apr 8 15:47 UA250 || Apr 13 17:05 UA251 || [[User:Puiterwijk|Patrick Uiterwijk]] || $600 (handled from Platform dept) || yes<br />
|-<br />
| [[User:Pingou|Pierre-Yves Chibon]] || Apr 7 15:50 - AF0054 || Apr 13 17:40 - AF6697 || [[User:Rbarlow|Randy Barlow]] || $1200 (flight + train) (handled from Platform dept) || yes (flight)<br />
|-<br />
| [[User:Sinnykumari|Sinny Kumari]] || Apr 8 15:35 - IAD(QR 707) || Apr 13 20:25 - IAD(QR 708) || || $1150 (flight) (handled from Platform dept) || yes<br />
|-<br />
| [[User:Ryanlerch|Ryan Lerch]] || || || [[User:Bstinson|Brian Stinson]] || $2283 (handled from Platform dept) || yes<br />
|-<br />
| [[User:Jperrin|Jim Perrin]] || || || || $700 - $800 (handled from OSAS) || yes<br />
|-<br />
| [[User:Bstinson|Brian Stinson]] || || || [[User:Ryanlerch|Ryan Lerch]] || $600-$700 (handled from OSAS) || yes<br />
|-<br />
| [[User:mattdm|Matthew Miller]] || Apr 8 18:08 Amtrak || Apr 13 8:00 Amtrak ||| (handled from FPL budget)|| yes<br />
|}<br />
<br />
== Planning Prerequisites ==<br />
<br />
See the [[How to organize a FAD]] list; you can keep your to-do list here.<br />
<br />
* Work out budget<br />
** Travel fares -- ~$? (nb to advise)<br />
** Lodging -- 8 rooms * $129/night + tax * 5 nights = approx. $6500<br />
** Meals -- est. $2500?<br />
** Rental cars -- $800-1000 max for two vans<br />
** Meeting room -- $1175 for week (sponsored by Ansible)<br />
** '''TOTAL: ~$10K from Fedora budget'''<br />
* Decide on Dates and Location<br />
** April 9-13<br />
** Arrivals: Sunday April 8; departures: Friday April 13<br />
* Arrange Facilities<br />
** Fredericksburg:<br />
*** Travel<br />
**** Recommended airport: Washington Dulles (IAD), about 68 miles (110km); also Reagan National (DCA), about 55 miles (90km); and Richmond International (RIC), about 70 miles (115km)<br />
**** IAD recommended for international travelers<br />
*** Workspace<br />
**** [http://president.umw.edu/events/campus-event-venues/stafford-campus/ University of Mary Washington - Stafford Graduate Campus] -- corporate classroom - $125/half-day<br />
*** Lodging<br />
**** [https://hiltongardeninn3.hilton.com/en/hotels/virginia/hilton-garden-inn-fredericksburg-DCAFHGI/index.html Hilton Garden Inn]<br />
*** Rental vehicles<br />
**** ~$1000 for two minivan rentals contract carrier (max)<br />
*** Social (Thursday)<br />
**** https://strangewaysbrewing.com/book-events/fxbg-book-events/<br />
**** or other local pub/restaurant<br />
* List Resources<br />
* Be Somewhat Structured<br />
* Arrange Lodging<br />
* Arrange Refreshments<br />
* <strike>Arrange a Social Event</strike> -- N/A<br />
<br />
== Plan ==<br />
# '''Location:''' Fredericksburg, VA<br />
#* Lodging: [https://hiltongardeninn3.hilton.com/en/hotels/virginia/hilton-garden-inn-fredericksburg-DCAFHGI/index.html Hilton Garden Inn Fredericksburg]<br />
# '''Date:''' April 9-13<br />
#* Arrivals: Sunday April 8<br />
# '''Remote Attendees:''' {{fpchat|#fedora-admin}}<br />
# '''Schedule'''<br />
#* Event starts 09:30 daily<br />
#* Event ends by 12:00pm Friday April 13, to allow for travel outbound<br />
<br />
== Logistics ==<br />
<br />
* '''Travel to hotel:''' Travelers will group by arrival and travel via rental car from IAD (Dulles, VA) to the hotel in Fredericksburg. Travel time on Sunday afternoon is between 70-90 minutes depending on traffic conditions.<br />
* '''Snacks/Beverages:''' Limited access due to the nature of the graduate campus. Monday will give us an idea how we can accommodate during the event.<br />
* '''Meals:'''<br />
** Breakfast before event -- venues TBD, meet in lobby of hotel at 08:15 daily<br />
** Lunch -- venues TBD, 12:30-13:45 daily<br />
** Dinner -- venues TBD after event ends (17:30)<br />
<br />
== Travel estimates ==<br />
<br />
{| class="wikitable"<br />
! Contributor !! Taxi/transport (to/from home) !! Airfare !! Taxi/transport (to/from site) !! Parking !! Other <br />
|-<br />
| || || || || ||<br />
|}<br />
<br />
# '''Travel:''' (TOTAL) (est)<br />
# '''Housing:''' (TOTAL) (est)<br />
# '''Space:'''<br />
#* (COST) - Supplied by (LOCATION)<br />
# '''Supplies:'''<br />
#* N/A<br />
# '''Food:''' (TOTAL) (est -- to be paid by Fedora Engineering budget)<br />
<br />
''Total budget: (TOTAL) estimated''<br />
<br />
<br />
[[Category:FAD]]</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Infrastructure/Kerberos&diff=512180Infrastructure/Kerberos2018-03-05T20:23:49Z<p>Puiterwijk: rdns=false</p>
<hr />
<div>= Infrastructure kerberos authentication =<br />
<br />
== Background ==<br />
<br />
Starting in November 2016, Fedora Infrastructure began to use kerberos authentication for some services, starting with koji (the Fedora build system). On December 12th 2016, the koji buildsystem will be switched to only allow kerberos authentication, and disallow the old ssl cert authentication. <br />
<br />
== Supported Services ==<br />
<br />
* koji<br />
<br />
* All Fedora Infrastructure ipsilon using applications via GSSAPI<br />
<br />
== Technical Details ==<br />
<br />
Fedora Infrastructure still uses the Fedora Account System (FAS), but now it syncs some account information to a pair of FreeIPA servers. Those servers are made available via a web proxy to Fedora contributors. Also, via the [https://pagure.io/ipsilon ipsilon] identity management server and GSSAPI we are able to use Kerberos tickets to authenticate users to any services that use ipsilon.<br />
<br />
== How to use kerberos auth with Fedora Infrastructure ==<br />
<br />
=== Command line ===<br />
<br />
* Store your FAS username (all lower case) in <code>~/.fedora.upn</code> (This is not actually needed for Kerberos but for other tools that used the Fedora client certificate to determine the FAS username)<br />
* <code>kinit <yourfasloginname>@FEDORAPROJECT.ORG</code><br />
** (Yes, upper-case FEDORAPROJECT.ORG — that's the convention for Kerberos.)<br />
** You need to do this regularly whenever fedpkg or koji authentication fail. There is no support for these tools to prompt you automatically when the ticket expired.<br />
** Install the <code>krb5-workstation</code> package (<code>sudo dnf install krb5-workstation</code>) if you do not have <code>kinit</code> command available.<br />
** You can set <code>default_realm = FEDORAPROJECT.ORG</code> in <code>/etc/krb5.conf</code> to avoid each typing <code>@FEDORAPROJECT.ORG</code>.<br />
* Enter your FAS password<br />
* You should now be able to authenticate to supported services (koji and lookaside upload)<br />
<br />
* Tickets are valid for 24 hours and can be renewed for 1 week. You can renew a existing ticket with <code>kinit -R <yourfasloginname>@FEDORAPROJECT.ORG</code><br />
<br />
=== GUI (gnome/workstation) ===<br />
<br />
* Open settings -> Online Accounts -> Click on the + to add an account -> Click on "Other" at the end of the list -> Click on "Enterprise login (kerberos)"<br />
* Enter FEDORAPROJECT.ORG for the domain<br />
* Enter your FAS name in the name field. <br />
* Enter your password when prompted. <br />
<br />
=== Firefox ===<br />
<br />
If you have Firefox 49 or higher and not tweaked any special configuration, you are done.<br />
If you have a lower version or want to check:<br />
* Go to about:config<br />
* Click the "I accept the risk" button<br />
* Search for "network.negotiate-auth.trusted-uris"<br />
* Double-click this option if it's not set to "https://", and set it to "https://"<br />
<br />
=== Chromium/Chrome ===<br />
<br />
For Chrome/Chromium, you need to create a policy file.<br />
<br />
* For Chromium, the directory to put this in is /etc/chromium/policies/managed/ .<br />
* For Chrome, the directory is /etc/opt/chrome/policies/managed/ (you might have to create this yourself).<br />
<br />
In that, create a file (e.g. fedora_kerberos.json), with contents:<br />
<br />
<pre><br />
{<br />
"AuthServerWhitelist": "*.fedoraproject.org",<br />
"AuthNegotiateDelegateWhitelist": "*.fedoraproject.org"<br />
}<br />
</pre><br />
<br />
<br />
For Mac Chrome/Chromium, you need to enter command<br />
<br />
<pre><br />
<br />
sudo defaults write /Library/Preferences/com.google.Chrome.plist AuthServerWhitelist '.fedoraproject.org'<br />
sudo defaults write /Library/Preferences/com.google.Chrome.plist AuthNegotiateDelegateWhitelist '.fedoraproject.org'<br />
<br />
</pre><br />
<br />
== Questions and Answers ==<br />
<br />
'''Question:''' Is there any particular format for username / domain I need to use?<br />
<br />
'''Answer:''' Yes. Your username should be all lower case, and the domain name should be all UPPER CASE. ie, <code>username@FEDORAPROJECT.ORG</code><br />
<br />
'''Question:''' I have 2 (or more) domains I login to with kerberos and koji only seems to work when it's the last one I add, whats going on? (The error it will show is "Kerberos authentication failed: Server not found in Kerberos database (-1765328377)")<br />
<br />
'''Answer:''' koji currently requires this, but there's a patch coming to fix it. In the mean time you can use <code>kswitch</code> to switch which is primary. <br />
<br />
'''Question:''' How can I see how long my ticket(s) are valid for?<br />
<br />
'''Answer:''' use <code>klist -A</code><br />
<br />
'''Question:''' I don't seem to be logged into the koji web interface after this, why not?<br />
<br />
'''Answer:''' Logging into the koji web interface doesn't really get you much of anything, but we are working on a patch to get this working down the road.<br />
<br />
'''Question:''' When I run kinit I get: Client 'yourname@FEDORAPROJECT.ORG' not found in Kerberos database while getting initial credentials<br />
<br />
'''Answer:''' Login to [https://admin.fedoraproject.org/accounts FAS] and then retry. Your information needs to be synced from FAS to the IPA server. Logging into FAS does so.<br />
<br />
'''Question:''' I did that (logged into FAS) in the last answer, and it didn't help, I still get the same error message. What's going on?<br />
<br />
'''Answer:''' For some small number of users there may be some issue with syncing information from fas->ipa. If this happens to you, please file an infrastructure ticket or talk with us on {{fpchat|#fedora-admin}} and we can manually fix things. <br />
<br />
'''Question:''' It's not working for me, how can I gather debugging information?<br />
<br />
'''Answer:''' Run the command with <code>KRB5_TRACE=/dev/stdout</code> in front of it and it should print a lot of debugging information. <br />
<br />
'''Question:''' koji and/or fedpkg don't seem to be working for me.<br />
<br />
'''Answer:''' Make sure you have upgraded to the versions listed above and also make sure you fold changes from <code>/etc/koji.conf.rpmnew</code> (if you ever modified your <code>/etc/koji.conf</code>) and your <code>~/.koji/config</code>. Note that in normal operation you can just use the stock <code>/etc/koji.conf</code> from the koji package and there is no need for a <code>~/.koji/config</code>. If it still doesn't work also check <code>/etc/rpkg/fedpkg.conf.rpmnew</code> and update your old config if it exists.<br />
<br />
'''Question:''' Where should I report problems or get help? <br />
<br />
'''Answer:''' {{fpchat|#fedora-admin}} on IRC or [https://pagure.io/fedora-infrastructure/issues file a fedora-infrastructure ticket] and we will try and assist you!<br />
<br />
'''Question:''' "kinit: Cannot find KDC for realm "FEDORAPROJECT.ORG" while getting initial credentials"?<br />
<br />
'''Answer:''' Try adding "includedir /etc/krb5.conf.d/" as the top line in the /etc/krb5.conf file<br />
<br />
'''Question:''' After entering my password I get: Password incorrect while getting initial credentials<br />
<br />
'''Answer:''' Please make sure you enter your correct password. If you are sure you entered the correct password, but it doesn't work, please visit the [https://admin.fedoraproject.org/accounts/ Fedora Account System] and log in and change your password. '''NOTE: Resetting your password does *NOT* update the Kerberos password.''' If you forgot your password, first use the password reset feature and then log in again to FAS and use the change password link.<br />
<br />
'''Question:''' Using Koji, I get an error "ImportError: Please install python-krbV to use kerberos"<br />
<br />
'''Answer:''' Please make sure that in /etc/krb5.conf, under [libdefaults], the option "rdns = false" is set. Note that this might break some non-Fedora krb5 services, but this is required to make GSSAPI work against Fedora services.<br />
<br />
== Debugging problems ==<br />
<br />
There is [https://github.com/puiterwijk/KrbDebug/blob/master/KrbDebug a script that can check you configuration] and tell you if there is any common problem. Just clone the repository and run the script.<br />
<br />
<pre><br />
$ git clone https://github.com/puiterwijk/KrbDebug.git<br />
$ cd KrbDebug/<br />
$ ./KrbDebug<br />
</pre><br />
<br />
== Extra info for Infrastructure people ==<br />
<br />
To access nagios, you need to use Kerberos as well.<br />
This will require you to change /etc/krb5.conf, and under [libdefaults] add or set "rdns = false" and "dns_canonicalize_hostname = false".</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Infrastructure_Hackathon_2018/Travel&diff=510990Infrastructure Hackathon 2018/Travel2018-02-08T17:01:21Z<p>Puiterwijk: </p>
<hr />
<div>Enter your potential (or actual) travel details here, along with expected costs. This way we can present a useful budget for the Council and other stakeholders.<br />
<br />
{| class="table"<br />
|-<br />
! Name !! Travel mode<br/>Air, train, car? !! Arrival time/info !! Departure time/info !! Notes<br />
|-<br />
| Stephen SMoogen || Train or Truck || 2018-04-08 || 2018-04-13 || Have spacesuit, will travel - Amtrak $92<br />
|-<br />
| Randy Barlow || Train or maybe smooge's truck || 2018-04-08 (10:02 - 15:06) || 2018-04-13 (12:21 - 17:29) || Amtrak is $92 (or rent van in RDU?)<br />
|-<br />
| pingou || Air || 2018-04-07 15:50 AF... IAD || 2018-04-13 17:40 AF... IAD || ~750€ for the airfare -- need a ride from there + train for home <-> Paris (~150€)<br />
|-<br />
| kevin || air || 2018-04-08 15:47pm IAD || 2018-04-13 17:05pm IAD || ~584 for airfaire, need ride to/from and car parking (10/day)<br />
|-<br />
| puiterwijk || Air || 2018-04-08 15:35 IAD - EI0119 || 2018-04-13 17:15 IAD - EI0118 || €812,35 for the airfare -- need a ride from IAD<br />
|-<br />
| ryanlerch || Air || 2018-04-08 || 2018-04-13 || ~2200USD for the airfare -- need a ride from there<br />
|-<br />
|}</div>Puiterwijkhttps://fedoraproject.org/w/index.php?title=Infrastructure_Hackathon_2018/Travel&diff=510989Infrastructure Hackathon 2018/Travel2018-02-08T17:00:41Z<p>Puiterwijk: </p>
<hr />
<div>Enter your potential (or actual) travel details here, along with expected costs. This way we can present a useful budget for the Council and other stakeholders.<br />
<br />
{| class="table"<br />
|-<br />
! Name !! Travel mode<br/>Air, train, car? !! Arrival time/info !! Departure time/info !! Notes<br />
|-<br />
| Stephen SMoogen || Train or Truck || 2018-04-08 || 2018-04-13 || Have spacesuit, will travel - Amtrak $92<br />
|-<br />
| Randy Barlow || Train or maybe smooge's truck || 2018-04-08 (10:02 - 15:06) || 2018-04-13 (12:21 - 17:29) || Amtrak is $92 (or rent van in RDU?)<br />
|-<br />
| pingou || Air || 2018-04-07 15:50 AF... IAD || 2018-04-13 17:40 AF... IAD || ~750€ for the airfare -- need a ride from there + train for home <-> Paris (~150€)<br />
|-<br />
| kevin || air || 2018-04-08 15:47pm IAD || 2018-04-13 17:05pm IAD || ~584 for airfaire, need ride to/from and car parking (10/day)<br />
|-<br />
| puiterwijk || Air || 2018-04-08 15:35 IAD - EI0119 || 2018-04-13 17:15 IAD - EI0118 || ~900€ for the airfare -- need a ride from there<br />
|-<br />
| ryanlerch || Air || 2018-04-08 || 2018-04-13 || ~2200USD for the airfare -- need a ride from there<br />
|-<br />
|}</div>Puiterwijk