Re: F35 Change: Remove SHA-1 from Sqlite (Self-Contained Change proposal)
On Wed, 2021-07-14 at 14:13 -0400, Paul Wouters wrote: > On Mon, 12 Jul 2021, Simo Sorce wrote: > > > > SQLite is a general-purpose tool. Not every use of SHA-1 is > > > cryptographically relevant. Most uses in the context of SQLite probably > > > aren't, so the removal just annoys users for no good reason. > > > > Note that this is a Sqlite decision, from RHEL engineering we only > > requested the removal in digital signatures and where integrity > > protection is required for security. > > Also note that we do not require full removal, just that SHA-1 is not > > used unless users intentionally change configuration. > > How does this affect users of NSS who have created "default" databases, > eg using certutil -N ? Do these use SHA1? If so, can they be migrated > to SHA2? Automatically ? I do not think this feature is used by NSS, CCing Bob. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Remove SHA-1 from Sqlite (Self-Contained Change proposal)
This change won't be applied, so no action is required. Ondrej On Wed, Jul 14, 2021 at 8:14 PM Paul Wouters wrote: > On Mon, 12 Jul 2021, Simo Sorce wrote: > > >> SQLite is a general-purpose tool. Not every use of SHA-1 is > >> cryptographically relevant. Most uses in the context of SQLite probably > >> aren't, so the removal just annoys users for no good reason. > > > > Note that this is a Sqlite decision, from RHEL engineering we only > > requested the removal in digital signatures and where integrity > > protection is required for security. > > Also note that we do not require full removal, just that SHA-1 is not > > used unless users intentionally change configuration. > > How does this affect users of NSS who have created "default" databases, > eg using certutil -N ? Do these use SHA1? If so, can they be migrated > to SHA2? Automatically ? > > Paul > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Remove SHA-1 from Sqlite (Self-Contained Change proposal)
On Mon, 12 Jul 2021, Simo Sorce wrote: SQLite is a general-purpose tool. Not every use of SHA-1 is cryptographically relevant. Most uses in the context of SQLite probably aren't, so the removal just annoys users for no good reason. Note that this is a Sqlite decision, from RHEL engineering we only requested the removal in digital signatures and where integrity protection is required for security. Also note that we do not require full removal, just that SHA-1 is not used unless users intentionally change configuration. How does this affect users of NSS who have created "default" databases, eg using certutil -N ? Do these use SHA1? If so, can they be migrated to SHA2? Automatically ? Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Remove SHA-1 from Sqlite (Self-Contained Change proposal)
On Fri, 2021-07-09 at 20:22 +0200, Florian Weimer wrote: > * Ben Cotton: > > > == Detailed Description == > > The use of SHA-1 is no longer permitted for Digital Signatures or > > authentication in RHEL-9. Due to this reason, there is a need to > > remove SHA-1 extension from sqlite in RHEL-9 and therefore also > > Fedora. The removal of the extension was discussed with sqlite > > upstream development, who confirmed, that it is safe to remove it and > > should not impact other functionality of sqlite. > > Why can we keep SHA-1 in coreutils and Git, but not in SQLite? That > does not make sense to me. > > SQLite is a general-purpose tool. Not every use of SHA-1 is > cryptographically relevant. Most uses in the context of SQLite probably > aren't, so the removal just annoys users for no good reason. Note that this is a Sqlite decision, from RHEL engineering we only requested the removal in digital signatures and where integrity protection is required for security. Also note that we do not require full removal, just that SHA-1 is not used unless users intentionally change configuration. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Remove SHA-1 from Sqlite (Self-Contained Change proposal)
Hello, According to the response from upstream [1], it seems I have come up with a solution too quickly. I apologize for this. I will go through a cancellation process of this Change Proposal, as there seems to be no valid reason to remove SHA-1 support in sqlite. Thanks for your help and understanding. Regards, Ondrej [1] https://sqlite.org/forum/forumpost/eec8e1bc739aee7d?raw On Sun, Jul 11, 2021 at 7:04 PM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > On Sat, Jul 10, 2021 at 12:13:20AM +0200, Felix Schwarz wrote: > > > > Am 09.07.21 um 17:45 schrieb Ben Cotton: > > >== Detailed Description == > > >The use of SHA-1 is no longer permitted for Digital Signatures or > > >authentication in RHEL-9. Due to this reason, there is a need to > > >remove SHA-1 extension from sqlite in RHEL-9 and therefore also > > >Fedora. > > > > I don't think that this is a valid logical conclusion. Fedora is > > (should be?) upstream to RHEL 9 so you can disable SHA1 in RHEL 9 > > but keep it enabled in Fedora. There is certainly no "need" for this > > change as demonstrated by the various packaging changes done in > > RHEL. > > > > (FWIW I don't particularly care about SHA1 functionality in sqlite.) > > Also: if it is not the recommended choice, why not just select > something else as the default (which is already the case, iiuc), > and let users use sha-1 to access existing databases? > > Zbyszek > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Remove SHA-1 from Sqlite (Self-Contained Change proposal)
On Sat, Jul 10, 2021 at 12:13:20AM +0200, Felix Schwarz wrote: > > Am 09.07.21 um 17:45 schrieb Ben Cotton: > >== Detailed Description == > >The use of SHA-1 is no longer permitted for Digital Signatures or > >authentication in RHEL-9. Due to this reason, there is a need to > >remove SHA-1 extension from sqlite in RHEL-9 and therefore also > >Fedora. > > I don't think that this is a valid logical conclusion. Fedora is > (should be?) upstream to RHEL 9 so you can disable SHA1 in RHEL 9 > but keep it enabled in Fedora. There is certainly no "need" for this > change as demonstrated by the various packaging changes done in > RHEL. > > (FWIW I don't particularly care about SHA1 functionality in sqlite.) Also: if it is not the recommended choice, why not just select something else as the default (which is already the case, iiuc), and let users use sha-1 to access existing databases? Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Remove SHA-1 from Sqlite (Self-Contained Change proposal)
Am 09.07.21 um 17:45 schrieb Ben Cotton: == Detailed Description == The use of SHA-1 is no longer permitted for Digital Signatures or authentication in RHEL-9. Due to this reason, there is a need to remove SHA-1 extension from sqlite in RHEL-9 and therefore also Fedora. I don't think that this is a valid logical conclusion. Fedora is (should be?) upstream to RHEL 9 so you can disable SHA1 in RHEL 9 but keep it enabled in Fedora. There is certainly no "need" for this change as demonstrated by the various packaging changes done in RHEL. (FWIW I don't particularly care about SHA1 functionality in sqlite.) Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Remove SHA-1 from Sqlite (Self-Contained Change proposal)
* Ben Cotton: > == Detailed Description == > The use of SHA-1 is no longer permitted for Digital Signatures or > authentication in RHEL-9. Due to this reason, there is a need to > remove SHA-1 extension from sqlite in RHEL-9 and therefore also > Fedora. The removal of the extension was discussed with sqlite > upstream development, who confirmed, that it is safe to remove it and > should not impact other functionality of sqlite. Why can we keep SHA-1 in coreutils and Git, but not in SQLite? That does not make sense to me. SQLite is a general-purpose tool. Not every use of SHA-1 is cryptographically relevant. Most uses in the context of SQLite probably aren't, so the removal just annoys users for no good reason. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Remove SHA-1 from Sqlite (Self-Contained Change proposal)
On 7/9/21 11:48 AM, Ben Cotton wrote: On Fri, Jul 9, 2021 at 11:45 AM Ben Cotton wrote: == Upgrade/compatibility impact == SHA-1 algorithm will not be supported in sqlite. Instead SHA-3 algorithm can be used. == User Experience == Users won't be able to use SHA-1 algorithm with sqlite. Instead, they can use SHA-3 algorithm, or any other supported algorithm. So what's the story for people who are currently using SHA-1? Is there an upgrade path for their DBs? Will stuff just stop working? sqlite uses SHA for checksumming the entire databases and tables (with the .sha3sum CLI command), and also provides it as a SQL function, presumably to store hashes in SQL tables. As far as I know, it hasn't provided the SHA1 version for a while: sqlite-3.34.1-2.fc34 seems to only provide the sha3 256-bit versions. I think that people who used SHA1 must have developed workarounds already. Having said that, I personally didn't use SHA in sqlite so I may be missing something. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Remove SHA-1 from Sqlite (Self-Contained Change proposal)
On 7/9/21 11:45 AM, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/Sqlite_SHA-1 == Summary == Removal of deprecated crypto algorithm SHA-1 from sqlite. == Owner == * Name: [[User:odubaj| Ondrej Dubaj]] * Email: odu...@redhat.com == Detailed Description == The use of SHA-1 is no longer permitted for Digital Signatures or authentication in RHEL-9. Due to this reason, there is a need to remove SHA-1 extension from sqlite in RHEL-9 and therefore also Fedora. The removal of the extension was discussed with sqlite upstream development, who confirmed, that it is safe to remove it and should not impact other functionality of sqlite. == Benefit to Fedora == This change brings update in terms of removing usage of deprecated crypto algorithms as users should not use them. Also it keeps Fedora project up-to-date with the newest RHEL release, what is beneficial for future releases. Why is this a remove proposal and not a default disabling via crypto policies. Will RHEL-9 remove SHA1 code from Java and other developer tools too instead of the current default disabled? == Scope == * Proposal owners: ** Prepare patch for removing SHA-1 algorithm from sqlite ** Discuss the possible issues with upstream ** Push the changes to Fedora * Other developers: Do not use SHA-1 algorithm in sqlite * Release engineering: No further coordination is required for this change * Policies and guidelines: No guidelines need to be updated according to this change * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == SHA-1 algorithm will not be supported in sqlite. Instead SHA-3 algorithm can be used. == How To Test == No special testing is required for this change. == User Experience == Users won't be able to use SHA-1 algorithm with sqlite. Instead, they can use SHA-3 algorithm, or any other supported algorithm. == Dependencies == == Contingency Plan == * Contingency mechanism: moving this change to Fedora 36, if not successfully finished until Fedora 35 branching from Rawhide * Contingency deadline: Fedora 35 branching from Rawhide (2021-08-10) * Blocks release? No == Documentation == Sqlite documentation: https://www.sqlite.org/docs.html Discussion with upstream about removing SHA-1 algorithm: https://sqlite.org/forum/forumpost/de1c4a92f3 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Remove SHA-1 from Sqlite (Self-Contained Change proposal)
On Fri, Jul 9, 2021 at 11:45 AM Ben Cotton wrote: > > == Upgrade/compatibility impact == > SHA-1 algorithm will not be supported in sqlite. Instead SHA-3 > algorithm can be used. > > == User Experience == > Users won't be able to use SHA-1 algorithm with sqlite. Instead, they > can use SHA-3 algorithm, or any other supported algorithm. > So what's the story for people who are currently using SHA-1? Is there an upgrade path for their DBs? Will stuff just stop working? -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F35 Change: Remove SHA-1 from Sqlite (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/Sqlite_SHA-1 == Summary == Removal of deprecated crypto algorithm SHA-1 from sqlite. == Owner == * Name: [[User:odubaj| Ondrej Dubaj]] * Email: odu...@redhat.com == Detailed Description == The use of SHA-1 is no longer permitted for Digital Signatures or authentication in RHEL-9. Due to this reason, there is a need to remove SHA-1 extension from sqlite in RHEL-9 and therefore also Fedora. The removal of the extension was discussed with sqlite upstream development, who confirmed, that it is safe to remove it and should not impact other functionality of sqlite. == Benefit to Fedora == This change brings update in terms of removing usage of deprecated crypto algorithms as users should not use them. Also it keeps Fedora project up-to-date with the newest RHEL release, what is beneficial for future releases. == Scope == * Proposal owners: ** Prepare patch for removing SHA-1 algorithm from sqlite ** Discuss the possible issues with upstream ** Push the changes to Fedora * Other developers: Do not use SHA-1 algorithm in sqlite * Release engineering: No further coordination is required for this change * Policies and guidelines: No guidelines need to be updated according to this change * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == SHA-1 algorithm will not be supported in sqlite. Instead SHA-3 algorithm can be used. == How To Test == No special testing is required for this change. == User Experience == Users won't be able to use SHA-1 algorithm with sqlite. Instead, they can use SHA-3 algorithm, or any other supported algorithm. == Dependencies == == Contingency Plan == * Contingency mechanism: moving this change to Fedora 36, if not successfully finished until Fedora 35 branching from Rawhide * Contingency deadline: Fedora 35 branching from Rawhide (2021-08-10) * Blocks release? No == Documentation == Sqlite documentation: https://www.sqlite.org/docs.html Discussion with upstream about removing SHA-1 algorithm: https://sqlite.org/forum/forumpost/de1c4a92f3 -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
