F35 Change: Remove SHA-1 from Sqlite (Self-Contained Change proposal)

[Ben Cotton]

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: odubaj(a)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

[Ben Cotton]

On Fri, Jul 9, 2021 at 11:45 AM Ben Cotton <bcotton(a)redhat.com&gt; 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

[przemek klosowski]

On 7/9/21 11:48 AM, Ben Cotton wrote:
>  On Fri, Jul 9, 2021 at 11:45 AM Ben Cotton <bcotton(a)redhat.com&gt;
> 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.

[Robert Marcano]

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: odubaj(a)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
>  
>  
>  
>

[Florian Weimer]

* 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

[Simo Sorce]

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

[Paul Wouters]

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

[Ondrej Dubaj]

This change won't be applied, so no action is required.

Ondrej

On Wed, Jul 14, 2021 at 8:14 PM Paul Wouters <paul(a)nohats.ca&gt; 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>

[Simo Sorce]

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

[Felix Schwarz]

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

[Zbigniew Jędrzejewski-Szmek]

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

[Ondrej Dubaj]

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 <
zbyszek(a)in.waw.pl&gt; 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>