Re: crypto-policies
Hi Zbyszek, Thanks for the clarifications. Neal On Mon, 27 Mar 2023 14:32:58 +0200, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Mar 27, 2023 at 01:29:38PM +0200, Neal H. Walfield wrote: > > On Mon, 27 Mar 2023 13:16:45 +0200, > > Zbigniew Jędrzejewski-Szmek wrote: > > > I agree. The scope of the issue is fairly narrow, and the underlying > > > issue is an invalid signature made by the anydesk maintainers. > > > We also have a simple command that users can use to work around > > > the issue. > > > > If you are thinking of sq-keyring-linter, that won't help here. This > > is not a SHA-1 issue. > > I know. I mentioned neither of those two things ;) > > The workaround I had in mind: add '--exclude-anydesk'. > We don't have a good replacement for graphical users yet, but I'm > sure we'll be able to write something up in CommonBugs before F38 is released. > > > The issue (I think) is that the anydesk maintains were too aggressive > > in what they striped when they exported the OpenPGP certificate. > [snip] > > Yes, probably. Anyway, the end result is that "based on the knowledge > that Sequoia has, the certificate was not valid when the signature was > made." (This is based on your comment [1]. I'm reproducing this > here for others.) > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=2170878#c124 > > 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, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: crypto-policies
On Mon, Mar 27, 2023 at 01:29:38PM +0200, Neal H. Walfield wrote: > On Mon, 27 Mar 2023 13:16:45 +0200, > Zbigniew Jędrzejewski-Szmek wrote: > > I agree. The scope of the issue is fairly narrow, and the underlying > > issue is an invalid signature made by the anydesk maintainers. > > We also have a simple command that users can use to work around > > the issue. > > If you are thinking of sq-keyring-linter, that won't help here. This > is not a SHA-1 issue. I know. I mentioned neither of those two things ;) The workaround I had in mind: add '--exclude-anydesk'. We don't have a good replacement for graphical users yet, but I'm sure we'll be able to write something up in CommonBugs before F38 is released. > The issue (I think) is that the anydesk maintains were too aggressive > in what they striped when they exported the OpenPGP certificate. [snip] Yes, probably. Anyway, the end result is that "based on the knowledge that Sequoia has, the certificate was not valid when the signature was made." (This is based on your comment [1]. I'm reproducing this here for others.) [1] https://bugzilla.redhat.com/show_bug.cgi?id=2170878#c124 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: crypto-policies
On Mon, 27 Mar 2023 13:16:45 +0200, Zbigniew Jędrzejewski-Szmek wrote: > I agree. The scope of the issue is fairly narrow, and the underlying > issue is an invalid signature made by the anydesk maintainers. > We also have a simple command that users can use to work around > the issue. If you are thinking of sq-keyring-linter, that won't help here. This is not a SHA-1 issue. The issue (I think) is that the anydesk maintains were too aggressive in what they striped when they exported the OpenPGP certificate. They probably ran: `gpg --export --export-options export-minimal FINGERPRINT`. According to the gpg manual page, that does: ``` export-minimal Export the smallest key possible. This removes all signatures except the most recent self-signature on each user ID. This option is the same as running the '--edit-key' command "minimize" before export except that the local copy of the key is not modified. Defaults to no. ``` This makes sense when sharing an OpenPGP certificate via email, say, so that someone can (in the future) send you an encrypted message. But it doesn't make sense when sending the certificate to someone who should then verify past signatures, which is the case here. Neal ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: crypto-policies
On Mon, Mar 27, 2023 at 11:40:05AM +0200, Fabio Valentini wrote:
> On Mon, Mar 27, 2023 at 11:23 AM Kamil Paral wrote:
> >
> > On Sat, Mar 25, 2023 at 8:20 AM Neal H. Walfield wrote:
> >>
> >> Panu wrote https://bugzilla.redhat.com/show_bug.cgi?id=2170878#c126 :
> >>
> >> > To me the key points here are
> >> > 1) there's a lot of obsolete/broken crypto out there
> >> > 2) we need better error messages
> >> >
> >> > Properly dealing with 2) needs an API redesign, but we'll try to work
> >> > out some sort of bandaid solution.
> >>
> >> Are better diagnostics sufficient from your point of view, or are you
> >> looking for a different solution?
> >
> >
> > I think my question in
> > https://bugzilla.redhat.com/show_bug.cgi?id=2170878#c125 wasn't really
> > answered, or at least I don't understand the implications.
>
> *putting on both my FESCo and rpm-sequoia package maintainer hats*
>
> The issue which was voted on for blocker status by FESCo ("In order to
> unblock, RPM must accept SHA-1 hashes and DSA keys for Fedora 38
> (...)") has been resolved.
> As far as I can tell, the anydesk case is different. It's not a
> problem caused by the new crypto policy - the packages don't use a
> SHA-1 signature - but happens because the Sequoia PGP implementation
> is stricter about checking signatures for sanity / validity.
> If I understand correctly, the packages are signed with a key that
> fails validation, so I'm inclined to say "this is not our problem"
> (and it also looks like this is an issue that's specific to this
> third-party package vendor, in contrast to the original SHA-1 / DSA
> issue which affected repositories that are officially endorsed by
> Fedora Workstation).
I agree. The scope of the issue is fairly narrow, and the underlying
issue is an invalid signature made by the anydesk maintainers.
We also have a simple command that users can use to work around
the issue.
The way that this is handled by rpm/dnf can be improved, but
we shouldn't block the release on this, and we should also track
this in #2170878, it is long enough already.
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: crypto-policies
On 3/27/23 12:40, Fabio Valentini wrote:
On Mon, Mar 27, 2023 at 11:23 AM Kamil Paral wrote:
On Sat, Mar 25, 2023 at 8:20 AM Neal H. Walfield wrote:
Panu wrote https://bugzilla.redhat.com/show_bug.cgi?id=2170878#c126 :
To me the key points here are
1) there's a lot of obsolete/broken crypto out there
2) we need better error messages
Properly dealing with 2) needs an API redesign, but we'll try to work out some
sort of bandaid solution.
Are better diagnostics sufficient from your point of view, or are you
looking for a different solution?
I think my question in https://bugzilla.redhat.com/show_bug.cgi?id=2170878#c125
wasn't really answered, or at least I don't understand the implications.
Kamil, would've been good to state that in the bug then. I only saw this
email by sheer luck.
*putting on both my FESCo and rpm-sequoia package maintainer hats*
The issue which was voted on for blocker status by FESCo ("In order to
unblock, RPM must accept SHA-1 hashes and DSA keys for Fedora 38
(...)") has been resolved.
As far as I can tell, the anydesk case is different. It's not a
problem caused by the new crypto policy - the packages don't use a
SHA-1 signature - but happens because the Sequoia PGP implementation
is stricter about checking signatures for sanity / validity.
If I understand correctly, the packages are signed with a key that
fails validation, so I'm inclined to say "this is not our problem"
(and it also looks like this is an issue that's specific to this
third-party package vendor, in contrast to the original SHA-1 / DSA
issue which affected repositories that are officially endorsed by
Fedora Workstation).
Indeed. The RpmSequoia change is not really about phasing out any
specific algorithms, that's a different topic. The anydesk case is
actually a fine showcase of Sequoia doing exactly what the change is
advertising! Only it's getting drowned in this SHA1/DSA noise, and poor
error messages (which is rpm's, not Sequoias fault).
- Panu -
___
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: crypto-policies
On Mon, Mar 27, 2023 at 11:23 AM Kamil Paral wrote:
>
> On Sat, Mar 25, 2023 at 8:20 AM Neal H. Walfield wrote:
>>
>> Panu wrote https://bugzilla.redhat.com/show_bug.cgi?id=2170878#c126 :
>>
>> > To me the key points here are
>> > 1) there's a lot of obsolete/broken crypto out there
>> > 2) we need better error messages
>> >
>> > Properly dealing with 2) needs an API redesign, but we'll try to work out
>> > some sort of bandaid solution.
>>
>> Are better diagnostics sufficient from your point of view, or are you
>> looking for a different solution?
>
>
> I think my question in
> https://bugzilla.redhat.com/show_bug.cgi?id=2170878#c125 wasn't really
> answered, or at least I don't understand the implications.
*putting on both my FESCo and rpm-sequoia package maintainer hats*
The issue which was voted on for blocker status by FESCo ("In order to
unblock, RPM must accept SHA-1 hashes and DSA keys for Fedora 38
(...)") has been resolved.
As far as I can tell, the anydesk case is different. It's not a
problem caused by the new crypto policy - the packages don't use a
SHA-1 signature - but happens because the Sequoia PGP implementation
is stricter about checking signatures for sanity / validity.
If I understand correctly, the packages are signed with a key that
fails validation, so I'm inclined to say "this is not our problem"
(and it also looks like this is an issue that's specific to this
third-party package vendor, in contrast to the original SHA-1 / DSA
issue which affected repositories that are officially endorsed by
Fedora Workstation).
Fabio
___
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: crypto-policies
On Sat, Mar 25, 2023 at 8:20 AM Neal H. Walfield wrote: > Panu wrote https://bugzilla.redhat.com/show_bug.cgi?id=2170878#c126 : > > > To me the key points here are > > 1) there's a lot of obsolete/broken crypto out there > > 2) we need better error messages > > > > Properly dealing with 2) needs an API redesign, but we'll try to work > out some sort of bandaid solution. > > Are better diagnostics sufficient from your point of view, or are you > looking for a different solution? > I think my question in https://bugzilla.redhat.com/show_bug.cgi?id=2170878#c125 wasn't really answered, or at least I don't understand the implications. ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
crypto-policies
Hi Ben, Thanks for working on this. On Fri, 24 Mar 2023 19:25:46 +0100, Ben Cotton wrote: > Accepted blockers > - > > 1. crypto-policies ― Insecure installed RPMs (like Google Chrome) > prevent system updates in F38, can't be removed ― ASSIGNED > ACTION: Maintainers to propose solution for this case ... > Bug-by-bug detail > = > > Accepted blockers > - > > 1. crypto-policies ― > https://bugzilla.redhat.com/show_bug.cgi?id=2170878 ― ASSIGNED > Insecure installed RPMs (like Google Chrome) prevent system updates in > F38, can't be removed > > A fix to let RPM use a separate crytpo policy has not covered all > cases. Certain AnyDesk RPMs were apparently signed outside the window > when the certificate was valid. Panu wrote https://bugzilla.redhat.com/show_bug.cgi?id=2170878#c126 : > To me the key points here are > 1) there's a lot of obsolete/broken crypto out there > 2) we need better error messages > > Properly dealing with 2) needs an API redesign, but we'll try to work out > some sort of bandaid solution. Are better diagnostics sufficient from your point of view, or are you looking for a different solution? Thanks in advance for providing some more clarity here. Neal ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: crypto-policies and a certain usage of SHA-1
On Fri, 2021-10-15 at 10:33 -0500, Michael Catanzaro wrote: > On Fri, Oct 15 2021 at 10:10:38 AM +0200, Björn Persson > wrote: > > My question is: Is it true that this usage of SHA-1 makes the TLS > > session weak, so that it's correct to forbid it in the crypto policy? > > Hm, I think Fedora's crypto policy should not be stricter than upstream > Firefox. This should probably be allowed. > > Enterprise distros are intentionally trying to be stricter and > completely remove SHA-1, but Fedora is not an enterprise distro and > breaking websites that work fine everywhere else is not OK for Fedora. > > > Or could it be that Qualys is right? Perhaps SHA-1 is fine for this > > use > > case, even though it's too weak for other use cases, and the crypto > > policy should allow it? > > SHA-1 is blocked in certificate signatures because those can be > attacked offline. Signatures in the TLS handshake are entirely > different. I'm hardly an expert, but I think the attacker only has a > few seconds to generate a hash collision before the user gives up and > closes the browser tab. Spending several months trying to find a > collision is not an option here. Am I wrong? Session keys are important not just for MiTM attacks, but also for store and decrypt attacks. TLS connections often channel a host of important private information that can be quite valuable even weeks or years after they are transmitted, including credentials. A weak session key will allow store and later decryption of communications, therefore retrieval of sensitive data. HTH, 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: crypto-policies and a certain usage of SHA-1
Michael Catanzaro wrote: > SHA-1 is blocked in certificate signatures because those can be > attacked offline. Signatures in the TLS handshake are entirely > different. I'm hardly an expert, but I think the attacker only has a > few seconds to generate a hash collision before the user gives up and > closes the browser tab. Spending several months trying to find a > collision is not an option here. Am I wrong? Probing the server repeatedly I get the same value in the Pubkey field several times in a row. Some time later the value changes. The server seems to replace the key every few hours or days. The Signature field is different every time though. Thus I'm not sure whether the attacker's time limit is the lifetime of the key (which Fedora can't control) or the TCP timeout. Björn Persson pgptnItUABZ9M.pgp Description: OpenPGP digital signatur ___ 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: crypto-policies and a certain usage of SHA-1
On Fri, Oct 15 2021 at 10:10:38 AM +0200, Björn Persson wrote: My question is: Is it true that this usage of SHA-1 makes the TLS session weak, so that it's correct to forbid it in the crypto policy? Hm, I think Fedora's crypto policy should not be stricter than upstream Firefox. This should probably be allowed. Enterprise distros are intentionally trying to be stricter and completely remove SHA-1, but Fedora is not an enterprise distro and breaking websites that work fine everywhere else is not OK for Fedora. Or could it be that Qualys is right? Perhaps SHA-1 is fine for this use case, even though it's too weak for other use cases, and the crypto policy should allow it? SHA-1 is blocked in certificate signatures because those can be attacked offline. Signatures in the TLS handshake are entirely different. I'm hardly an expert, but I think the attacker only has a few seconds to generate a hash collision before the user gives up and closes the browser tab. Spending several months trying to find a collision is not an option here. Am I wrong? Michael ___ 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
crypto-policies and a certain usage of SHA-1
Hello, I have a question for someone with deep knowledge about cryptology. The question regards Fedora's crypto policies and a certain usage of SHA-1 in TLS. I encountered a web server that Seamonkey and Firefox refuse to talk to. Both give me the error SSL_ERROR_UNSUPPORTED_SIGNATURE_ALGORITHM. In an attempt to find out more, I checked the server with Qualys' SSL Server Test (https://www.ssllabs.com/ssltest/). Qualys gave it an A+, which is supposed to mean that its security is excellent. Next I used Wireshark to inspect the TLS handshake. Wireshark reported usage of SHA-1, not in the certificate but in a signature associated with elliptic curve parameters: | TLSv1.2 Record Layer: Handshake Protocol: Server Key Exchange | Content Type: Handshake (22) | Version: TLS 1.2 (0x0303) | Length: 333 | Handshake Protocol: Server Key Exchange | Handshake Type: Server Key Exchange (12) | Length: 329 | EC Diffie-Hellman Server Params | Curve Type: named_curve (0x03) | Named Curve: secp256r1 (0x0017) | Pubkey Length: 65 | Pubkey: 041f840f40a2178f875274097092ca2549138f8a7bd52df895ea413b742d1714a6cf873e… | Signature Algorithm: rsa_pkcs1_sha1 (0x0201) | Signature Hash Algorithm Hash: SHA1 (2) | Signature Hash Algorithm Signature: RSA (1) | Signature Length: 256 | Signature: 09147d81aa601dc402e62cf7f943196c89822a0c8bbe07d8443654519b0e04f51b0b8e72… To check whether this was the problem, I temporarily added "SHA1" to /etc/crypto-policies/back-ends/nss.config. This made the error go away, and the browser happily loaded the page. My question is: Is it true that this usage of SHA-1 makes the TLS session weak, so that it's correct to forbid it in the crypto policy? Or could it be that Qualys is right? Perhaps SHA-1 is fine for this use case, even though it's too weak for other use cases, and the crypto policy should allow it? The website where I saw this is https://www.euroclear.com/ in case anyone wants to test things themself. Björn Persson pgptX2bBu9PZE.pgp Description: OpenPGP digital signatur ___ 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
[Bug 1851243] perl-Test-Fake-HTTPD: FTBFS with crypto-policies-20200625-1.gitb298a9e.fc33
https://bugzilla.redhat.com/show_bug.cgi?id=1851243 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|CLOSED Link ID||Github ||masaki/Test-Fake-HTTPD/pull ||/5 Fixed In Version||perl-Test-Fake-HTTPD-0.08-1 ||2.fc33 Resolution|--- |RAWHIDE Last Closed||2020-06-26 12:11:26 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1851243] perl-Test-Fake-HTTPD: FTBFS with crypto-policies-20200625-1.gitb298a9e.fc33
https://bugzilla.redhat.com/show_bug.cgi?id=1851243 Petr Pisar changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|de...@fateyev.com |ppi...@redhat.com -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-de...@lists.fedoraproject.org
[Bug 1851243] perl-Test-Fake-HTTPD: FTBFS with crypto-policies-20200625-1.gitb298a9e.fc33
https://bugzilla.redhat.com/show_bug.cgi?id=1851243 Petr Pisar changed: What|Removed |Added Summary|perl-Test-Fake-HTTPD: FTBFS |perl-Test-Fake-HTTPD: FTBFS |in Fedora rawhide |with ||crypto-policies-20200625-1. ||gitb298a9e.fc33 --- Comment #4 from Petr Pisar --- It's triggered by upgrading crypto-policies from 20200610-1.git7f9d474.fc33 to 20200625-1.gitb298a9e.fc33. Changelog: * Thu Jun 25 2020 Tomáš Mráz - 20200625-1.gitb298a9e - DEFAULT policy: Drop DH < 2048 bits, TLS 1.0, 1.1, SHA-1 - make the NEXT policy just an alias for DEFAULT as they are now identical - policies: introduce sha1_in_dnssec value for BIND - add SHA1 and FEDORA32 policy modules to provide backwards compatibility they can be applied as DEFAULT:SHA1 or DEFAULT:FEDORA32 - avoid duplicates of list items in resulting policy * Wed Jun 24 2020 Tomáš Mráz - 20200619-1.git781bbd4 - gnutls: enable DSA signatures in LEGACY * Wed Jun 10 2020 Tomáš Mráz - 20200610-1.git7f9d474 I guess the bundled testing keys do pass the new criteria. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: Rawhide broken: crypto-policies
On Fri, May 29, 2020 at 10:25 AM Igor Raits wrote: > This is fixed now. > > https://bugzilla.redhat.com/show_bug.cgi?id=1841851 Thank you for the quick response. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Rawhide broken: crypto-policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-05-29 at 10:08 -0600, Jerry James wrote: > Trying to build a package just now failed > (https://koji.fedoraproject.org/koji/taskinfo?taskID=45145531): > > Running transaction check > Transaction check succeeded. > Running transaction test > Transaction test succeeded. > Running transaction > error: lua script failed: [string > "%prein(crypto-policies-20200527-3.gitb234a47.fc33.noarch)"]:19: > attempt to call a nil value > > Error in PREIN scriptlet in rpm package crypto-policies > error: crypto-policies-20200527-3.gitb234a47.fc33.noarch: install > failed This is fixed now. https://bugzilla.redhat.com/show_bug.cgi?id=1841851 > > -- > Jerry James > http://www.jamezone.org/ > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7RNzUACgkQEV1auJxc Hh63xg/9EbBPd1jZ/0T8Dz3/te4VtBYFwV6Z/8WuRmnuINADIoFw18bd3VsFur7z e1tyuEZUxHVpvg0WJA43ktJxYeG8cVQoyXeTdD4wIAW7DWIuFIE9IKSyGLpajxXQ /TNlIjyR52zcUsltrbra64NB0+WP8I25HzjVbumzB4jWEl8/XIqFBja9Qaco1Z06 6odCLzdpuKVzJDqHXubhVI1ZnKX61tDPlDsGp/BH/+wb48/sos31dRAHoR22dhwl uzlyBsbfvcvZrLr/RmBQtZCXHyXbrtI5S3aPMNX1GcQkG5UOc4WxZWHhJb09AA2B Rs5PmU+O8MNk3t5VX3Ra6FhbsrG+tk+eRzZ2voxYBiWbFBNDbhmoGqAFgvxgNCRj dfQc0V5rMUxpoM1KglNUAKDJuZP2lW3K3KvQyXchnaG/uwNPxneJxsmgavRFB0yC 2HAL2f16TQbfABGw8kFy9Vc1lghbTZu2cTgaVjwYLd0IOVqntzQ0iSpFK5P5D/8B F+TBknkYwcfp2WotNLAAtd1dBkEy9Z6CWAHUKcMfUgdWt0FDvL3syJa4GQSe+/++ GgUcR8/SqX3Gszv8RnhYk2ziq3quEj8pcaUNEk+7Aia/8Xj60O6uou0zGBxU29EO i1b4h98ftK2rmdet+OJTbBeikLmnRSyTghgLpWF6mmwED6SM5W0= =OETP -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Rawhide broken: crypto-policies
On 29. 05. 20 18:08, Jerry James wrote: Trying to build a package just now failed (https://koji.fedoraproject.org/koji/taskinfo?taskID=45145531): Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction error: lua script failed: [string "%prein(crypto-policies-20200527-3.gitb234a47.fc33.noarch)"]:19: attempt to call a nil value Error in PREIN scriptlet in rpm package crypto-policies error: crypto-policies-20200527-3.gitb234a47.fc33.noarch: install failed https://bugzilla.redhat.com/show_bug.cgi?id=1841851 Mohan and Igor are untagging the build now. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Rawhide broken: crypto-policies
Trying to build a package just now failed (https://koji.fedoraproject.org/koji/taskinfo?taskID=45145531): Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction error: lua script failed: [string "%prein(crypto-policies-20200527-3.gitb234a47.fc33.noarch)"]:19: attempt to call a nil value Error in PREIN scriptlet in rpm package crypto-policies error: crypto-policies-20200527-3.gitb234a47.fc33.noarch: install failed -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F31 Self-Contained Change proposal: Custom Crypto Policies
On Wed, 2019-06-19 at 12:38 +0200, Vít Ondruch wrote: > Dne 18. 06. 19 v 21:50 Ben Cotton napsal(a): > > == How To Test == > > > > This will be tested as part of the upstream crypto-policies > > testsuite. > > I think this section should describe, how I, as a Fedora user, am > supposed to test this. E.g. > > 1) Get this test package > > 2) Modify this file > > 3) Run this command > > 4) And as a result, you can now verify by this command that this new > crypto-policy is applied. As this is self-contained change I am not sure this is necessary. However I might provide test instructions or rather some kind of how-to as part of the crypto-policies documentation. -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F31 Self-Contained Change proposal: Custom Crypto Policies
On Wed, 2019-06-19 at 12:49 +0200, Vít Ondruch wrote: > Dne 19. 06. 19 v 12:00 Tomas Mraz napsal(a): > > On Wed, 2019-06-19 at 10:19 +0200, Vít Ondruch wrote: > > > Dne 18. 06. 19 v 21:50 Ben Cotton napsal(a): > > > > https://fedoraproject.org/wiki/Changes/CustomCryptoPolicies > > > > > > > > == Summary == > > > > This new feature of crypto-policies allows system > > > > administrators > > > > and > > > > third party providers to modify and adjust the existing system- > > > > wide > > > > crypto policies to enable or disable algorithms and protocols. > > > > > > > > == Owner == > > > > * Name: [[User:Tmraz | Tomáš Mráz]] > > > > * Email: tm...@redhat.com > > > > > > > > == Detailed Description == > > > > > > > > The crypto-policies package will be enhanced to allow system > > > > administrators to modify the existing system-wide crypto policy > > > > levels > > > > by removing or adding enabled algorithms and protocols. For > > > > example > > > > it > > > > will be possible to easily modify the existing DEFAULT > > > I just wonder what is the strategy here? Does it means that the > > > "DEFAULT" definition will be store permanently somewhere in /usr/ > > > and > > > I'll be able to copy the DEFAULT into /etc and modify it > > > according to > > > my > > > needs? > > > > > > I am just asking, because AFAIK, currently the crypto policies > > > configuration is stored just in /etc and modifying the "DEFAULT" > > > profile > > > would make the updates problematic, requiring someone to file > > > with > > > .rpmnew files etc. That would be unfortunate. > > The configuration files will be created by a simple python > > application > > (which the update-crypto-policies will transform into). You will > > specify just the modifications that should be done to the base > > policy. > > > > Please see > > https://gitlab.com/redhat-crypto/fedora-crypto-policies/tree/custom-policies > > > > to get the idea. > > > > We might continue shipping the "unmodified" configurations in > > /usr/share but I do not see much benefit in that except for being > > able > > for the sysadmin to look at how the unmodified individual > > configurations look like without applying the policy to the system. > > > > Looking at "unmodified" configuration is great benefit on itself. Unmodified from what? What I meant above were the unmodified pristine DEFAULT, LEGACY, FUTURE or FIPS configurations, not something like library default configuration without crypto policies. > Being able to `rm -rf /etc/cryptopolicies` (or whatever is the right > folder) to restore the original configuration would be even better. > But > maybe the "update-crypto-policies" creates configuration files for > several cryptolibraries, so this might not be possible without > modification of those libraries, dunno. But no such thing was ever possible since crypto policies were introduced and there is currently no plan to do that. This is certainly out of scope for the Custom Crypto Policies change. I am also not sure what do you mean exactly by "original configuration" - do you mean the configuration if there was no crypto-policies on the system? Then that would require more configuration handling changes on the individual crypto backend libraries/applications. -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F31 Self-Contained Change proposal: Custom Crypto Policies
Dne 19. 06. 19 v 12:00 Tomas Mraz napsal(a): > On Wed, 2019-06-19 at 10:19 +0200, Vít Ondruch wrote: >> Dne 18. 06. 19 v 21:50 Ben Cotton napsal(a): >>> https://fedoraproject.org/wiki/Changes/CustomCryptoPolicies >>> >>> == Summary == >>> This new feature of crypto-policies allows system administrators >>> and >>> third party providers to modify and adjust the existing system-wide >>> crypto policies to enable or disable algorithms and protocols. >>> >>> == Owner == >>> * Name: [[User:Tmraz | Tomáš Mráz]] >>> * Email: tm...@redhat.com >>> >>> == Detailed Description == >>> >>> The crypto-policies package will be enhanced to allow system >>> administrators to modify the existing system-wide crypto policy >>> levels >>> by removing or adding enabled algorithms and protocols. For example >>> it >>> will be possible to easily modify the existing DEFAULT >> I just wonder what is the strategy here? Does it means that the >> "DEFAULT" definition will be store permanently somewhere in /usr/ and >> I'll be able to copy the DEFAULT into /etc and modify it according to >> my >> needs? >> >> I am just asking, because AFAIK, currently the crypto policies >> configuration is stored just in /etc and modifying the "DEFAULT" >> profile >> would make the updates problematic, requiring someone to file with >> .rpmnew files etc. That would be unfortunate. > The configuration files will be created by a simple python application > (which the update-crypto-policies will transform into). You will > specify just the modifications that should be done to the base policy. > > Please see > https://gitlab.com/redhat-crypto/fedora-crypto-policies/tree/custom-policies > to get the idea. > > We might continue shipping the "unmodified" configurations in > /usr/share but I do not see much benefit in that except for being able > for the sysadmin to look at how the unmodified individual > configurations look like without applying the policy to the system. > Looking at "unmodified" configuration is great benefit on itself. Being able to `rm -rf /etc/cryptopolicies` (or whatever is the right folder) to restore the original configuration would be even better. But maybe the "update-crypto-policies" creates configuration files for several cryptolibraries, so this might not be possible without modification of those libraries, dunno. Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F31 Self-Contained Change proposal: Custom Crypto Policies
Dne 18. 06. 19 v 21:50 Ben Cotton napsal(a): > == How To Test == > > This will be tested as part of the upstream crypto-policies testsuite. I think this section should describe, how I, as a Fedora user, am supposed to test this. E.g. 1) Get this test package 2) Modify this file 3) Run this command 4) And as a result, you can now verify by this command that this new crypto-policy is applied. Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F31 Self-Contained Change proposal: Custom Crypto Policies
On Wed, 2019-06-19 at 10:19 +0200, Vít Ondruch wrote: > Dne 18. 06. 19 v 21:50 Ben Cotton napsal(a): > > https://fedoraproject.org/wiki/Changes/CustomCryptoPolicies > > > > == Summary == > > This new feature of crypto-policies allows system administrators > > and > > third party providers to modify and adjust the existing system-wide > > crypto policies to enable or disable algorithms and protocols. > > > > == Owner == > > * Name: [[User:Tmraz | Tomáš Mráz]] > > * Email: tm...@redhat.com > > > > == Detailed Description == > > > > The crypto-policies package will be enhanced to allow system > > administrators to modify the existing system-wide crypto policy > > levels > > by removing or adding enabled algorithms and protocols. For example > > it > > will be possible to easily modify the existing DEFAULT > > I just wonder what is the strategy here? Does it means that the > "DEFAULT" definition will be store permanently somewhere in /usr/ and > I'll be able to copy the DEFAULT into /etc and modify it according to > my > needs? > > I am just asking, because AFAIK, currently the crypto policies > configuration is stored just in /etc and modifying the "DEFAULT" > profile > would make the updates problematic, requiring someone to file with > .rpmnew files etc. That would be unfortunate. The configuration files will be created by a simple python application (which the update-crypto-policies will transform into). You will specify just the modifications that should be done to the base policy. Please see https://gitlab.com/redhat-crypto/fedora-crypto-policies/tree/custom-policies to get the idea. We might continue shipping the "unmodified" configurations in /usr/share but I do not see much benefit in that except for being able for the sysadmin to look at how the unmodified individual configurations look like without applying the policy to the system. -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F31 Self-Contained Change proposal: Custom Crypto Policies
Dne 18. 06. 19 v 21:50 Ben Cotton napsal(a): > https://fedoraproject.org/wiki/Changes/CustomCryptoPolicies > > == Summary == > This new feature of crypto-policies allows system administrators and > third party providers to modify and adjust the existing system-wide > crypto policies to enable or disable algorithms and protocols. > > == Owner == > * Name: [[User:Tmraz | Tomáš Mráz]] > * Email: tm...@redhat.com > > == Detailed Description == > > The crypto-policies package will be enhanced to allow system > administrators to modify the existing system-wide crypto policy levels > by removing or adding enabled algorithms and protocols. For example it > will be possible to easily modify the existing DEFAULT I just wonder what is the strategy here? Does it means that the "DEFAULT" definition will be store permanently somewhere in /usr/ and I'll be able to copy the DEFAULT into /etc and modify it according to my needs? I am just asking, because AFAIK, currently the crypto policies configuration is stored just in /etc and modifying the "DEFAULT" profile would make the updates problematic, requiring someone to file with .rpmnew files etc. That would be unfortunate. Vít > policy to > disable the SHA1 support or enable support for a national crypto > algorithm that is supported by the crypto libraries but is disabled in > the policies. System administrator will be able to add a simple > configuration file that will achieve this after calling the > update-crypto-policies command. > > == Benefit to Fedora == > > This will enable advanced users of Fedora to adjust the > crypto-policies of the system to their particular needs and > requirements. > > It will also enable using Fedora where the national crypto algorithms > are required without need to manually tinker with configurations of > various software components to enable the national crypto algorithms. > > == Scope == > * Proposal owners: > The design of the feature and prototype is already finished upstream. > We still need to convert the existing back-end policy generators to > the new framework and convert the existing policy definitions to the > new format. Then the crypto-policies package will be rebased to the > version with the custom crypto policies support included. > > * Other developers: N/A (not a System Wide Change) > * Release engineering: N/A (not a System Wide Change) > * Policies and guidelines: N/A (not a System Wide Change) > * Trademark approval: N/A (not needed for this Change) > > == Upgrade/compatibility impact == > > No impact. The crypto policies will continue to work as expected and > worked before if a custom policy is not set. > > == How To Test == > > This will be tested as part of the upstream crypto-policies testsuite. > > == User Experience == > > Unless the user will choose to create and/or apply a custom crypto > policy on the system, there will be no noticeable user experience > change. > > == Dependencies == > > N/A (not a System Wide Change) > > == Contingency Plan == > > * Contingency mechanism: (What to do? Who will do it?) N/A (not a > System Wide Change) > > == Documentation == > > N/A (not a System Wide Change) > > == Release Notes == > > The crypto-policies package was enhanced to allow system > administrators to modify the existing system-wide crypto policy levels > by removing or adding enabled algorithms and protocols. For example it > is now possible to easily modify the existing DEFAULT policy to > disable the SHA1 support or enable support for a national crypto > algorithm that is supported by the crypto libraries but is disabled in > the policies. This can be achieved by adding a simple configuration > file and calling the update-crypto-policies command. > ___ 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
F31 Self-Contained Change proposal: Custom Crypto Policies
https://fedoraproject.org/wiki/Changes/CustomCryptoPolicies == Summary == This new feature of crypto-policies allows system administrators and third party providers to modify and adjust the existing system-wide crypto policies to enable or disable algorithms and protocols. == Owner == * Name: [[User:Tmraz | Tomáš Mráz]] * Email: tm...@redhat.com == Detailed Description == The crypto-policies package will be enhanced to allow system administrators to modify the existing system-wide crypto policy levels by removing or adding enabled algorithms and protocols. For example it will be possible to easily modify the existing DEFAULT policy to disable the SHA1 support or enable support for a national crypto algorithm that is supported by the crypto libraries but is disabled in the policies. System administrator will be able to add a simple configuration file that will achieve this after calling the update-crypto-policies command. == Benefit to Fedora == This will enable advanced users of Fedora to adjust the crypto-policies of the system to their particular needs and requirements. It will also enable using Fedora where the national crypto algorithms are required without need to manually tinker with configurations of various software components to enable the national crypto algorithms. == Scope == * Proposal owners: The design of the feature and prototype is already finished upstream. We still need to convert the existing back-end policy generators to the new framework and convert the existing policy definitions to the new format. Then the crypto-policies package will be rebased to the version with the custom crypto policies support included. * Other developers: N/A (not a System Wide Change) * Release engineering: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == No impact. The crypto policies will continue to work as expected and worked before if a custom policy is not set. == How To Test == This will be tested as part of the upstream crypto-policies testsuite. == User Experience == Unless the user will choose to create and/or apply a custom crypto policy on the system, there will be no noticeable user experience change. == Dependencies == N/A (not a System Wide Change) == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) == Documentation == N/A (not a System Wide Change) == Release Notes == The crypto-policies package was enhanced to allow system administrators to modify the existing system-wide crypto policy levels by removing or adding enabled algorithms and protocols. For example it is now possible to easily modify the existing DEFAULT policy to disable the SHA1 support or enable support for a national crypto algorithm that is supported by the crypto libraries but is disabled in the policies. This can be achieved by adding a simple configuration file and calling the update-crypto-policies command. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-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-announce@lists.fedoraproject.org
F31 Self-Contained Change proposal: Custom Crypto Policies
https://fedoraproject.org/wiki/Changes/CustomCryptoPolicies == Summary == This new feature of crypto-policies allows system administrators and third party providers to modify and adjust the existing system-wide crypto policies to enable or disable algorithms and protocols. == Owner == * Name: [[User:Tmraz | Tomáš Mráz]] * Email: tm...@redhat.com == Detailed Description == The crypto-policies package will be enhanced to allow system administrators to modify the existing system-wide crypto policy levels by removing or adding enabled algorithms and protocols. For example it will be possible to easily modify the existing DEFAULT policy to disable the SHA1 support or enable support for a national crypto algorithm that is supported by the crypto libraries but is disabled in the policies. System administrator will be able to add a simple configuration file that will achieve this after calling the update-crypto-policies command. == Benefit to Fedora == This will enable advanced users of Fedora to adjust the crypto-policies of the system to their particular needs and requirements. It will also enable using Fedora where the national crypto algorithms are required without need to manually tinker with configurations of various software components to enable the national crypto algorithms. == Scope == * Proposal owners: The design of the feature and prototype is already finished upstream. We still need to convert the existing back-end policy generators to the new framework and convert the existing policy definitions to the new format. Then the crypto-policies package will be rebased to the version with the custom crypto policies support included. * Other developers: N/A (not a System Wide Change) * Release engineering: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == No impact. The crypto policies will continue to work as expected and worked before if a custom policy is not set. == How To Test == This will be tested as part of the upstream crypto-policies testsuite. == User Experience == Unless the user will choose to create and/or apply a custom crypto policy on the system, there will be no noticeable user experience change. == Dependencies == N/A (not a System Wide Change) == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) == Documentation == N/A (not a System Wide Change) == Release Notes == The crypto-policies package was enhanced to allow system administrators to modify the existing system-wide crypto policy levels by removing or adding enabled algorithms and protocols. For example it is now possible to easily modify the existing DEFAULT policy to disable the SHA1 support or enable support for a national crypto algorithm that is supported by the crypto libraries but is disabled in the policies. This can be achieved by adding a simple configuration file and calling the update-crypto-policies command. -- 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
Re: crypto-policies not very useful, FUTURE too strict?
On Mon, 2016-12-19 at 11:07 +0100, Tomasz Torcz wrote: > On Mon, Dec 19, 2016 at 09:35:09AM +0100, Nikos Mavrogiannopoulos > wrote: > > On Sat, 2016-12-17 at 16:19 +0100, Tomasz Torcz wrote: > > > Hi, > > > > > > Since few release we have nifty, consolidated way to select > > > system- > > > wide crypto > > > policy. It's great, but granularity of selection is little > > > lacking. > > > We have > > > basically two sensible choices: > > > - DEFAULT, which is, well, default > > > > That is one of the main goals of crypto policies. To set a sensible > > default across the system applications, irrespective of which back- > > end > > library it uses. It should not be underestimated, as even now we > > are > > not there yet, especially with the applications depending on the > > less > > known tls libraries, or applications using libssh*. > > > > As a general goal, the intention of the FUTURE policy is not to be > > compatible with the rest of the internet. That's the goal of the > > DEFAULT policy. The FUTURE is intended to be compatible with > > servers > > using parameters which are considered secure. > So, what exactly is the use case behind this preference? Administrators which need to set their system on a specific security level. Future is defined to be on the 112-bit level. regards, Nikos ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: crypto-policies not very useful, FUTURE too strict?
On Mon, 2016-12-19 at 09:35 +0100, Nikos Mavrogiannopoulos wrote: $ update-crypto-policies --set FUTURE Setting system policy to FUTURE $ wget https://github.com Resolving github.com (github.com)... 192.30.253.112, 192.30.253.113 github.com (github.com)|192.30.253.112|:443... connected ERROR: The certificate of 'github.com' is not trusted. ERROR: The certificate of 'github.com' was signed using an insecure algorithm. The example you have above is a glitch on the combination of the shared system store use and crypto policies at gnutls. Actually it relates to a particular behavior of wget [0]. In fact it was disabling the system-wide policy as soon as it was enabling it. [0]. https://bugzilla.redhat.com/show_bug.cgi?id=1405956 regards, Nikos ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: crypto-policies not very useful, FUTURE too strict?
On Mon, Dec 19, 2016 at 09:35:09AM +0100, Nikos Mavrogiannopoulos wrote: > On Sat, 2016-12-17 at 16:19 +0100, Tomasz Torcz wrote: > > Hi, > > > > Since few release we have nifty, consolidated way to select system- > > wide crypto > > policy. It's great, but granularity of selection is little lacking. > > We have > > basically two sensible choices: > > - DEFAULT, which is, well, default > > That is one of the main goals of crypto policies. To set a sensible > default across the system applications, irrespective of which back-end > library it uses. It should not be underestimated, as even now we are > not there yet, especially with the applications depending on the less > known tls libraries, or applications using libssh*. > > As a general goal, the intention of the FUTURE policy is not to be > compatible with the rest of the internet. That's the goal of the > DEFAULT policy. The FUTURE is intended to be compatible with servers > using parameters which are considered secure. So, what exactly is the use case behind this preference? > > $ update-crypto-policies --set FUTURE > > Setting system policy to FUTURE > > > > $ wget https://github.com > > Resolving github.com (github.com)... 192.30.253.112, > > 192.30.253.113 > > github.com > > (github.com)|192.30.253.112|:443... connected > > ERROR: The certificate of 'github.com' is not trusted. > > ERROR: The certificate of 'github.com' was signed using an insecure > > algorithm. > > The example you have above is a glitch on the combination of the shared > system store use and crypto policies at gnutls. Please file a bug on > it. That host should have been within the crypto policies FUTURE > requirements. Done: https://bugzilla.redhat.com/show_bug.cgi?id=1405959 -- Tomasz Torcz "Never underestimate the bandwidth of a station xmpp: zdzich...@chrome.plwagon filled with backup tapes." -- Jim Gray ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: crypto-policies not very useful, FUTURE too strict?
On Sat, 2016-12-17 at 16:19 +0100, Tomasz Torcz wrote: > Hi, > > Since few release we have nifty, consolidated way to select system- > wide crypto > policy. It's great, but granularity of selection is little lacking. > We have > basically two sensible choices: > - DEFAULT, which is, well, default That is one of the main goals of crypto policies. To set a sensible default across the system applications, irrespective of which back-end library it uses. It should not be underestimated, as even now we are not there yet, especially with the applications depending on the less known tls libraries, or applications using libssh*. > - FUTURE, which is said to be more secure; if the admin wants to > change the policy, > (s)he will have to switch to FUTURE > So let's imagine Joe Sysadmins who in the face of LogJam and other > vulnerabilites, > wants to tighten security a bit. He switches to FUTURE and now GitHub > doesn't work: As a general goal, the intention of the FUTURE policy is not to be compatible with the rest of the internet. That's the goal of the DEFAULT policy. The FUTURE is intended to be compatible with servers using parameters which are considered secure. > $ update-crypto-policies --set FUTURE > Setting system policy to FUTURE > > $ wget https://github.com > Resolving github.com (github.com)... 192.30.253.112, > 192.30.253.113 > github.com > (github.com)|192.30.253.112|:443... connected > ERROR: The certificate of 'github.com' is not trusted. > ERROR: The certificate of 'github.com' was signed using an insecure > algorithm. The example you have above is a glitch on the combination of the shared system store use and crypto policies at gnutls. Please file a bug on it. That host should have been within the crypto policies FUTURE requirements. > Should we introduce another level, like FUTURE-BUT-WORKING? With > secure settings, No. The purpose of the policies is to provide levels of assurance. A connection is within that set or not. FUTURE-BUT-WORKING doesn't mean anything; the DEFAULT policy serves that purpose. regards, Nikos ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: crypto-policies not very useful, FUTURE too strict?
On Sat, Dec 17, 2016 at 01:07:52PM -0500, Scott Schmit wrote: > On Sat, Dec 17, 2016 at 06:05:49PM +0100, Nicolas Chauvet wrote: > > Maybe we need to rename FUTURE by QUITE_SOON instead, because the > > error you have pointed is about sha-1 been deprecated: > > > > According to this blog, chrome will remove support for sha-1 > > certificates on 1 January 2017 (it's an old post, so I don't know if > > it's still current). > > https://security.googleblog.com/2015/12/an-update-on-sha-1-certificates-in.html > > > > the getfedora certificates is signed with sha-256, but the root CA has > > signed the intermediate certificate with sha-1. That the issue. > > Storing the root keys as certificates makes sense from an implementation > standpoint -- it conveniently associates the keys with the subject DNs > and other properties like key usage, but the self signature (or > otherwise) is already nonsense -- either I already trust the key (thus I > don't need to validate it) or I don't (in which case the signature can't > be trusted either). > > Thus, if the signature on the certs in the trust store matter, that's a > bug. The presence of the keys in the trust store should be all that's > required for them to be trusted -- the details of the signature > algorithm can't be irrelevant. "can't be relevant", I meant. smime.p7s Description: S/MIME cryptographic signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: crypto-policies not very useful, FUTURE too strict?
On Sat, Dec 17, 2016 at 06:05:49PM +0100, Nicolas Chauvet wrote: > Maybe we need to rename FUTURE by QUITE_SOON instead, because the > error you have pointed is about sha-1 been deprecated: > > According to this blog, chrome will remove support for sha-1 > certificates on 1 January 2017 (it's an old post, so I don't know if > it's still current). > https://security.googleblog.com/2015/12/an-update-on-sha-1-certificates-in.html > > the getfedora certificates is signed with sha-256, but the root CA has > signed the intermediate certificate with sha-1. That the issue. Storing the root keys as certificates makes sense from an implementation standpoint -- it conveniently associates the keys with the subject DNs and other properties like key usage, but the self signature (or otherwise) is already nonsense -- either I already trust the key (thus I don't need to validate it) or I don't (in which case the signature can't be trusted either). Thus, if the signature on the certs in the trust store matter, that's a bug. The presence of the keys in the trust store should be all that's required for them to be trusted -- the details of the signature algorithm can't be irrelevant. smime.p7s Description: S/MIME cryptographic signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: crypto-policies not very useful, FUTURE too strict?
On 17/12/16 17:05, Nicolas Chauvet wrote: Maybe we need to rename FUTURE by QUITE_SOON instead, because the error you have pointed is about sha-1 been deprecated: According to this blog, chrome will remove support for sha-1 certificates on 1 January 2017 (it's an old post, so I don't know if it's still current). https://security.googleblog.com/2015/12/an-update-on-sha-1-certificates-in.html the getfedora certificates is signed with sha-256, but the root CA has signed the intermediate certificate with sha-1. That the issue. As far as I can see both the intermediate and leaf certificates have SHA-256 signatures. It is only the root certificate that has an SHA-1 signature and that will still be allowed by chrome - to quote that blog post: "At this point, sites that have a SHA-1-based signature as part of the certificate chain (not including the self-signature on the root certificate) will trigger a fatal network error. So the self signature on the root certificate can still be SHA-1 because that certificate is in the root set and hence is valid simply by existing and it's signature algorithm doesn't really matter. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: crypto-policies not very useful, FUTURE too strict?
2016-12-17 16:19 GMT+01:00 Tomasz Torcz <to...@pipebreaker.pl>: > Hi, > > Since few release we have nifty, consolidated way to select system-wide > crypto > policy. It's great, but granularity of selection is little lacking. We have > basically two sensible choices: > - DEFAULT, which is, well, default > - FUTURE, which is said to be more secure; if the admin wants to change the > policy, > (s)he will have to switch to FUTURE > > So let's imagine Joe Sysadmins who in the face of LogJam and other > vulnerabilites, > wants to tighten security a bit. He switches to FUTURE and now GitHub doesn't > work: > > $ update-crypto-policies --set FUTURE > Setting system policy to FUTURE > > $ wget https://github.com > Resolving github.com (github.com)... 192.30.253.112, 192.30.253.113 > >Connecting to github.com > (github.com)|192.30.253.112|:443... connected. > ERROR: The certificate of 'github.com' is not trusted. > ERROR: The certificate of 'github.com' was signed using an insecure algorithm. > > Not only github: > > Connecting to getfedora.org (getfedora.org)|2001:4178:2:1269::fed2|:443... > connected. > ERROR: The certificate of 'getfedora.org' is not trusted. > ERROR: The certificate of 'getfedora.org' was signed using an insecure > algorithm. > > Switching back to DEFAULT make those working again. But it buys us nothing, > we have one setting which is default and the other is unusable. Why have this > setting at all, then? Maybe we need to rename FUTURE by QUITE_SOON instead, because the error you have pointed is about sha-1 been deprecated: According to this blog, chrome will remove support for sha-1 certificates on 1 January 2017 (it's an old post, so I don't know if it's still current). https://security.googleblog.com/2015/12/an-update-on-sha-1-certificates-in.html the getfedora certificates is signed with sha-256, but the root CA has signed the intermediate certificate with sha-1. That the issue. Thx for rising the point, I will check which certificates are still sha-1 in my own cert usage. -- - Nicolas (kwizart) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
crypto-policies not very useful, FUTURE too strict?
Hi, Since few release we have nifty, consolidated way to select system-wide crypto policy. It's great, but granularity of selection is little lacking. We have basically two sensible choices: - DEFAULT, which is, well, default - FUTURE, which is said to be more secure; if the admin wants to change the policy, (s)he will have to switch to FUTURE So let's imagine Joe Sysadmins who in the face of LogJam and other vulnerabilites, wants to tighten security a bit. He switches to FUTURE and now GitHub doesn't work: $ update-crypto-policies --set FUTURE Setting system policy to FUTURE $ wget https://github.com Resolving github.com (github.com)... 192.30.253.112, 192.30.253.113 Connecting to github.com (github.com)|192.30.253.112|:443... connected. ERROR: The certificate of 'github.com' is not trusted. ERROR: The certificate of 'github.com' was signed using an insecure algorithm. Not only github: Connecting to getfedora.org (getfedora.org)|2001:4178:2:1269::fed2|:443... connected. ERROR: The certificate of 'getfedora.org' is not trusted. ERROR: The certificate of 'getfedora.org' was signed using an insecure algorithm. Switching back to DEFAULT make those working again. But it buys us nothing, we have one setting which is default and the other is unusable. Why have this setting at all, then? Should we introduce another level, like FUTURE-BUT-WORKING? With secure settings, post-quantum cryptographic algorithms but working with today websites? -- Tomasz Torcz 72->| 80->| xmpp: zdzich...@chrome.pl 72->| 80->| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: enhancing crypto policies for other languages than C
On 2014-10-16, Nikos Mavrogiannopoulos n...@redhat.com wrote: The currently proposed fedora maintainer instructions for the system-wide crypto policy are mainly for the C language. Could some experienced in other languages (e.g., ruby/python) propose some text for them? https://fedoraproject.org/wiki/User:Nmav/CryptoPolicies Could you explain why replacing the cipher list is better than removing the call? Could you explain why the PROFILE= syntax is not documented in ciphers(1) (referred from SSL_CTX_set_cipher_list(3)). -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: enhancing crypto policies for other languages than C
On 2014-10-16, Nikos Mavrogiannopoulos n...@redhat.com wrote: The currently proposed fedora maintainer instructions for the system-wide crypto policy are mainly for the C language. Could some experienced in other languages (e.g., ruby/python) propose some text for them? https://fedoraproject.org/wiki/User:Nmav/CryptoPolicies I descibed handling some Perl modules there. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
enhancing crypto policies for other languages than C
Hello, The currently proposed fedora maintainer instructions for the system-wide crypto policy are mainly for the C language. Could some experienced in other languages (e.g., ruby/python) propose some text for them? https://fedoraproject.org/wiki/User:Nmav/CryptoPolicies regards, Nikos -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Crypto policies packaging guideline
Hello, (resurrecting an really old thread, sorry about the delay.) - Original Message - 1) Will I (as a hobbyist packager) be able to reach the proper conclusion, e.g. find the real place where these defaults are set, such as [4, 5]? If you, as the package maintainer, who knows the package, can’t do this, who can? The security experts can grep for SSL_CTX_set_cipher_list as well as anybody, but following through the call chain and multiple langauges does require package-specific expertise. A distribution is supposed to be a set of software customized to work well together, and yes, that necessarily means understanding the source code and being able to change it. We _need_ to be able to do such things with Fedora’s packages; perhaps we haven’t been asking packagers for this much recently, but we need to start, and this is as good a reason to start as any. 2) What about dynamic languages, such as Ruby, Python etc. They are not covered by the guidelines at all. Yes, it would be good to expand the guideline to cover the bindings of the major languages. 3) Should I really rewrite the upstream defaults and how? What will be the impact on other libraries written in Ruby? Not mentioning that there was quite lengthy controversial discussion upstream [6] and you ask me again to override its results. By my uninformed estimation, the vast majority of TLS using projects either don’t have an explicit configuration (i.e. there is nothing to be done), or are not carefully maintaining the cipher list, unlike this recent Ruby change; and even projects that have recently updated it are not automatically guaranteed to keep maintaining it in the future. Libraries written in Ruby _should_ in general inherit the system-wide defaults, though, yes, this may in very rare cases result in additional patching of these libraries if they are connecting to specific services that are less secure and need custom configuration. (It might be interesting to compare the Ruby defaults list and the current version of the PROFILE=SYSTEM list.) Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Crypto policies packaging guideline
- Original Message - IMHO, we need a crypto-expert or team to formally review this proposal, Nikos, who proposed this, is a crypto expert :) to identify packages it affects and to advise packagers and upstreams on how to implement this, because I feel this proposal is way beyond the scope of skill/knowledge of an average packager. The guidelines can and probably should be expanded to be more directly applicable to other languages, but IMHO making such a change in a package’s primary implementation language very much _needs_ to be within the scope of the skill expected of an average packager. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Crypto policies packaging guideline
Dne 27.8.2014 22:42, James Antill napsal(a): #topic #452 Crypto policies packaging guideline .fpc 452 https://fedorahosted.org/fpc/ticket/452 Looking into this topic and the proposed guidelines [1], I am not sure how to apply them for Ruby. On the first look, looking for SSL_CTX_set_cipher_list, it is called at [2]. It looks like some helper method, which in Ruby translates into #ciphers= method, which does not appear to be used anywhere. Nevertheless, if you look better, you can discover, that it is actually called at [4] and fed by some defaults [5]. This is not directly obvious. This raises several questions: 1) Will I (as a hobbyist packager) be able to reach the proper conclusion, e.g. find the real place where these defaults are set, such as [4, 5]? 2) What about dynamic languages, such as Ruby, Python etc. They are not covered by the guidelines at all. 3) Should I really rewrite the upstream defaults and how? What will be the impact on other libraries written in Ruby? Not mentioning that there was quite lengthy controversial discussion upstream [6] and you ask me again to override its results. Don't take me wrong, I support this effort. It just looks to have lot of blind spots. Vít [1] https://fedoraproject.org/wiki/User:Nmav/CryptoPolicies [2] https://github.com/ruby/ruby/blob/trunk/ext/openssl/ossl_ssl.c#L904 [3] https://github.com/ruby/ruby/blob/trunk/ext/openssl/ossl_ssl.c#L2113 [4] https://github.com/ruby/ruby/blob/trunk/ext/openssl/lib/openssl/ssl.rb#L86 [5] https://github.com/ruby/ruby/blob/trunk/ext/openssl/lib/openssl/ssl.rb#L26 [6] https://github.com/ruby/ruby/commit/699b209cf8cf11809620e12985ad33ae33b119ee -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Crypto policies packaging guideline
On 08/28/2014 08:55 AM, Vít Ondruch wrote: Dne 27.8.2014 22:42, James Antill napsal(a): #topic #452 Crypto policies packaging guideline .fpc 452 https://fedorahosted.org/fpc/ticket/452 Looking into this topic and the proposed guidelines [1], I am not sure how to apply them for Ruby. FPC discussed proposal briefly this during the meeting 2 weeks ago. AFAIR, we felt this proposal is beyond your knowledge and we feared this proposal to be inapplicable. IMHO, we need a crypto-expert or team to formally review this proposal, to identify packages it affects and to advise packagers and upstreams on how to implement this, because I feel this proposal is way beyond the scope of skill/knowledge of an average packager. That, said, I am not sure, this proposal should be made part of the FPG, but needs some kind of special treatment. Don't take me wrong, I support this effort. It just looks to have lot of blind spots. ACK. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
