< Features
No edit summary |
m (Removing QA category) |
||
| (20 intermediate revisions by 4 users not shown) | |||
| Line 13: | Line 13: | ||
== Current status == | == Current status == | ||
* Targeted release: [[Releases/11| Fedora 11]] | * Targeted release: [[Releases/11| Fedora 11]] | ||
* Last updated: | * Last updated: 2009-04-14 | ||
* Percentage of completion: | * Percentage of completion: 100% of functionality planned for Fedora 11. | ||
* Details: SHA-256 file hashes are used in the mass rebuild. repodata uses SHA-256. RPM package signatures use SHA-256. ISO checksum files and their signatures use SHA-256. There are many other packages that use hashes, most won't be modified in time for Fedora 11 (see [[Hash_algorithm_migration_status]]). | |||
== Detailed Description == | == Detailed Description == | ||
The widely-used MD5 and SHA-1 hashes have known vulnerabilities | The widely-used MD5 and SHA-1 hashes have known vulnerabilities ([http://en.wikipedia.org/wiki/MD5#Vulnerability], | ||
([http://en.wikipedia.org/wiki/MD5#Vulnerability], | [http://en.wikipedia.org/wiki/SHA-1#SHA-1]). These vulnerabilities do not break the hashes completely, but it is prudent to migrate to stronger hashes (e.g. the SHA-2 family) as soon as possible (see for example the tables in [[http://www.linuxworld.com/cgi-bin/mailto/x_linux.cgi?pagetosend=/export/home/httpd/linuxworld/news/2007/111207-hash.html]]). | ||
[http://en.wikipedia.org/wiki/SHA-1#SHA-1]). | |||
break the hashes completely, but it is prudent to migrate to stronger hashes | |||
(e.g. the SHA-2 family) as soon as possible (see for example the tables in | |||
[[http://www.linuxworld.com/cgi-bin/mailto/x_linux.cgi?pagetosend=/export/home/httpd/linuxworld/news/2007/111207-hash.html]]). | |||
As many packages as possible will have SHA-2 hash support added, focusing on | As many packages as possible will have SHA-2 hash support added, focusing on the most widely used and most security sensitive packages first. If it does not significantly affect interoperability, these hashes will be used by default. | ||
the most widely used and most security sensitive packages first. If it does | |||
not significantly affect interoperability, these hashes will be used by default. | |||
Of particular interest | Of particular interest is the RPM file format: The file format now has support for using stronger hashes in package signatures and payload file hashes (see [[RPM_file_format_changes_to_support_SHA-256]]), but it is not enabled by default. There are some interoperability issues when RPM packages using more than one hash type are used together (affecting updates of <code>%config</code> files that don't change their contents, and sharing identical files across packages that use different hashes - see [[https://bugzilla.redhat.com/show_bug.cgi?id=479869#c4]] for specifics). | ||
for using stronger hashes in package signatures and payload file hashes, but it | Tools that work with RPMs (e.g. koji) need to support the RPM file format extensions. | ||
is not enabled by default. There are some interoperability issues when | |||
RPM packages using more than one hash type are used together (affecting updates of %config files that don't change their contents, and sharing identical files across packages that use different hashes | |||
Tools that work with RPMs (e.g. koji) need to support the | |||
RPM file format extensions. | |||
Another important area is hashes used in repodata, repodata signatures, package signatures, and release signatures (the signed SHA1SUM file) | Another important area is hashes used in repodata, repodata signatures, package signatures, and release signatures (the signed <tt>SHA1SUM</tt> file). | ||
Not all uses of hashes are security relevant and need to be converted. | Not all uses of hashes are security relevant and need to be converted. For example, these uses can be vulnerable to attacks on hash algorithms: | ||
example, these uses can be vulnerable to attacks on hash algorithms: | |||
* Digital signatures | * Digital signatures | ||
| Line 59: | Line 49: | ||
certifiable for government use | certifiable for government use | ||
([http://csrc.nist.gov/groups/ST/hash/policy.html]). | ([http://csrc.nist.gov/groups/ST/hash/policy.html]). | ||
== Drawbacks == | |||
<tt>(yum upgrade)</tt> from Fedora 9 directly to Fedora 11 won't be possible (the necessary rpm backport would be too large). Upgrade from Fedora 9 to 10, then to 11, should work. Alternatively, a repo that provides the Fedora 11 rpm recompiled for F-9 can be provided (unsupported just like using yum to upgrade). | |||
Upgrades from RPM packages that use MD5 to packages that use SHA-2 (e.g. upgrade from F<11 to F11) will move all user-modified <code>%config</code> (not <code>%config(noreplace)</code>) files to <tt>.rpmsave</tt>. | |||
== Scope == | == Scope == | ||
For RPM file hashes: RPM | For RPM file hashes: RPM, koji, spacewalk. | ||
For repodata/release hashes and signatures: yum, createrepo, pungi. | For repodata/release hashes and signatures: yum, createrepo, pungi. | ||
At least one file copying tool | At least one file copying tool and one backup tool need to support SHA-256: scp and bacula appear to do so. | ||
As many other individual packages that use hashes as possible. | As many other individual packages that use hashes as possible. | ||
| Line 79: | Line 75: | ||
* No user action is necessary to continue to be able to use Fedora. | * No user action is necessary to continue to be able to use Fedora. | ||
* Users that require use of strong hashes at the cost of interoperability might have to configure some applications manually to use the strong hashes. | * Users that require use of strong hashes at the cost of interoperability might have to configure some applications manually to use the strong hashes. | ||
* RPM files generated on Fedora will not be installable on systems with older versions of RPM by default; | * RPM files generated on Fedora using the Fedora configuration (probably in <tt>redhat-rpm-config</tt>) will not be installable on systems with older versions of RPM by default; RPM macro definitions will be necessary to build backward-compatible RPMs | ||
== Dependencies == | == Dependencies == | ||
| Line 96: | Line 92: | ||
== Release Notes == | == Release Notes == | ||
See [[Documentation_Beats_Installer#Upgrade_Notes]] and [[Documentation_Security_Beat]]. | |||
== Comments and Discussion == | == Comments and Discussion == | ||
| Line 104: | Line 100: | ||
---- | ---- | ||
[[Category: | [[Category:FeatureAcceptedF11]] | ||
<!-- When your feature page is completed and ready for review --> | <!-- When your feature page is completed and ready for review --> | ||
<!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler --> | <!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler --> | ||
<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete--> | <!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete--> | ||
<!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process --> | <!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process --> | ||
Latest revision as of 17:36, 17 April 2009
Support and use hashes stronger than SHA-1
Summary
Support stronger hashes than MD5 and SHA-1 (focusing on SHA-2 in particular, but making it easy to migrate to other hashes in the future), and use them by default where appropriate.
Owner
- Name: Mitr
- Email: mitr@redhat.com
Current status
- Targeted release: Fedora 11
- Last updated: 2009-04-14
- Percentage of completion: 100% of functionality planned for Fedora 11.
- Details: SHA-256 file hashes are used in the mass rebuild. repodata uses SHA-256. RPM package signatures use SHA-256. ISO checksum files and their signatures use SHA-256. There are many other packages that use hashes, most won't be modified in time for Fedora 11 (see Hash_algorithm_migration_status).
Detailed Description
The widely-used MD5 and SHA-1 hashes have known vulnerabilities ([1], [2]). These vulnerabilities do not break the hashes completely, but it is prudent to migrate to stronger hashes (e.g. the SHA-2 family) as soon as possible (see for example the tables in [[3]]).
As many packages as possible will have SHA-2 hash support added, focusing on the most widely used and most security sensitive packages first. If it does not significantly affect interoperability, these hashes will be used by default.
Of particular interest is the RPM file format: The file format now has support for using stronger hashes in package signatures and payload file hashes (see RPM_file_format_changes_to_support_SHA-256), but it is not enabled by default. There are some interoperability issues when RPM packages using more than one hash type are used together (affecting updates of %config files that don't change their contents, and sharing identical files across packages that use different hashes - see [[4]] for specifics).
Tools that work with RPMs (e.g. koji) need to support the RPM file format extensions.
Another important area is hashes used in repodata, repodata signatures, package signatures, and release signatures (the signed SHA1SUM file).
Not all uses of hashes are security relevant and need to be converted. For example, these uses can be vulnerable to attacks on hash algorithms:
- Digital signatures
- Other uses of hashes to verify authenticity of data (e.g. the digitally signed SHA1SUM file that contains hashes of other files)
- Password encryption (/etc/shadow already uses SHA-2 in Fedora 10, but application-specific password stores often don't.)
These uses should be converted to better ensure integrity of important data:
- Detection of data corruption
These uses are probably not at risk:
- Combining data from various unpredictable sources into a few random bytes
Benefit to Fedora
A system more resistant to attacks on the hashes. This will also make it possible to build an operating system based on Fedora that will be certifiable for government use ([5]).
Drawbacks
(yum upgrade) from Fedora 9 directly to Fedora 11 won't be possible (the necessary rpm backport would be too large). Upgrade from Fedora 9 to 10, then to 11, should work. Alternatively, a repo that provides the Fedora 11 rpm recompiled for F-9 can be provided (unsupported just like using yum to upgrade).
Upgrades from RPM packages that use MD5 to packages that use SHA-2 (e.g. upgrade from F<11 to F11) will move all user-modified %config (not %config(noreplace)) files to .rpmsave.
Scope
For RPM file hashes: RPM, koji, spacewalk.
For repodata/release hashes and signatures: yum, createrepo, pungi.
At least one file copying tool and one backup tool need to support SHA-256: scp and bacula appear to do so.
As many other individual packages that use hashes as possible.
How To Test
- Where changes in packages are local, test the packages one by one.
- Enable SHA-2 hashes in RPM, build RPMs that use them. Test various scenarios of systems that combine packages that use SHA-2 hashes and MD5 hashes (file conflicts and %config file handling in particular).
User Experience
- No user action is necessary to continue to be able to use Fedora.
- Users that require use of strong hashes at the cost of interoperability might have to configure some applications manually to use the strong hashes.
- RPM files generated on Fedora using the Fedora configuration (probably in redhat-rpm-config) will not be installable on systems with older versions of RPM by default; RPM macro definitions will be necessary to build backward-compatible RPMs
Dependencies
None
Contingency Plan
- For isolated packages, revert the specific package.
- For RPM file format, revert the RPM configuration change and rebuild affected packages.
Documentation
None yet. Tracking bug #461972 [6].
Release Notes
See Documentation_Beats_Installer#Upgrade_Notes and Documentation_Security_Beat.
Comments and Discussion