Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)
On 4/17/24 12:54 AM, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Apr 17, 2024 at 09:38:30AM +0200, Miroslav Suchý wrote: Dne 17. 04. 24 v 9:20 dop. Zbigniew Jędrzejewski-Szmek napsal(a): By adding this functionality to Mock itself. It can be optional (--add-determinism). And then Mock can call add-determinism $chroot/%buildroot/ I don't think we should make this particular functionality special. We have a bunch of brps: It depends... if you want to have this check/sanitization part of rpmbuild. When it is small,and does not inflate buildroot, then fine. Over the years, I learn that people have different view where each component should go. :) I will not argue. If you package add-determinism I can help you to add it to Mock. Likely as plugin: https://rpm-software-management.github.io/mock/#plugins that is called in `postbuild` https://rpm-software-management.github.io/mock/Plugin-Hooks And by helping I mean that I will create the initial PR and you (and others) will test the functionality. Deal? Thank you for the offer. I _might_ take you up on it later, but for now, I think it's better to keep this inside of the buildroot. I don't think that this functionality should be tied to mock. Right now, the helper runs for 'fedpkg local' (as all brps), but if it's moved to mock, then we'd need to at least call it from two places. A lot of our security libraries create cryptographic checksums on the binaries that need to be correct in order for them to run in FIPS mode. If this is actually changing the binaries, we'll need to rerun those checksums. bob 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: RPM Sequoia: A Sequoia-based backend for the RPM Package Manager
On 4/27/23 3:51 AM, Neal H. Walfield wrote: Hi all, A year and a half ago, I began working with Panu on using Sequoia as RPM's OpenPGP parser. I wrote up our journey from the initial analysis, to adding the code to RPM, and to getting it into Fedora 38 (yay!) in a blog post. I'm mentioning it here, as I believe it is of general interest to this community. If this is considered off topic, I apologize in advance. https://sequoia-pgp.org/blog/2023/04/27/rpm-sequoia/ Thanks Neal. A good read indeed. I do wonder about the error message: || |because: SHA1 is not considered secure since 1970-01-01T00:00:00Z| I'm not sure where the date came from, but SHA1 wasn't published until 1993. 1970-01-01 looks like an epic of some kind. If you must include a 'not considered secure' date it should be something between 2010 and 2017 (2010 when peole started worrying about sha1, 2011 and 2013 when NIST said 'stop using it' and 2017 when Google (ironically - since they are the ones still signing packages with it) actually broke it). Probably best to drop the not considered secure if the received date is null|.| Bob|| ___ devel mailing list --devel@lists.fedoraproject.org To unsubscribe send an email todevel-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: ca-certificates latest updates and Mozilla NSS certdata.txt modifications
On 8/19/22 6:08 AM, Alexander Sosedkin wrote:
On Thu, Aug 18, 2022 at 1:45 PM Yann Droneaud wrote:
I've noticed ca-certificates package was updated recently, and went looking
at the changes, and I have some questions.
Not Bob Relyea, but I'll try to answer to the best of my knowledge:
Alexander is correct. Most of the information you are looking for is in :
https://bugzilla.redhat.com/show_bug.cgi?id=2117793
The certdata.txt is created by using scripts in
https://github.com/rjrelyea/ca-certificate-scripts, namely
fetch_objsign.sh and mergepem2certdata.py. The former fetches the
appropriate object signing list of certs and mergepem2certdata.py merges
it with the mozilla certdata.txt.
Certs that are only in the object signing list are marked in comments
("microsoft object signing only") and should only have the object
signing bit on. They won't show up in any extracted lists except
/etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem.
Certs that are in both lists keep the mozilla entry and have the object
signing trust attribute turned on.
Once there are versioned object signing releases from microsoft I'll
update the fetch scripts in the ca-certificate package on rawhide so
others can optionally pick up these changes as well (as well as adding
time-stamping support).
bob
The first issue is what certdata.txt was used ? It's supposed to be
downloaded from Mozilla NSS sources, but doesn't match any released
versions.
3.79, as suggested by both the changelog entries and
https://src.fedoraproject.org/rpms/ca-certificates/blob/rawhide/f/nssckbi.h
matching
https://hg.mozilla.org/projects/nss/raw-file/NSS_3_79_RTM/lib/ckfw/builtins/nssckbi.h
The second issue is what are the changes that were made to certdata.txt ?
The commit messages and RPM changelogs say the root CA certificate database
was updated thrice to the same version.
Below the 3 latest updates to certdata.txt used to build the root CA
certificates database in ca-certificates RPM package for Fedora Rawhide
from ca-certificates git repository
...
As you can find, the last 3 ca-certificate's certdata.txt version match
*no* NSS's certdata.txt which is suspicious.
In https://fedoraproject.org/wiki/CA-Certificates it is said, that since
Fedora 25, there's no modification on the upstream root certificates
database. So what happened here ?
Unfortunately, the ca-certificates' commit messages nor the RPM's changelog
provide any reason for the differences.
This raise the question of the trust we can have in the update, if the
certdata.txt supposedly imported from Mozilla NSS, doesn't match any file
released by Mozilla.
Indeed it doesn't.
If you diff it against Mozilla's
https://hg.mozilla.org/projects/nss/log/NSS_3_79_RTM/lib/ckfw/builtins/certdata.txt
you should observe significant differences of two varieties:
1. -CKA_TRUST_CODE_SIGNING CK_TRUST CKT_NSS_MUST_VERIFY_TRUST
+CKA_TRUST_CODE_SIGNING CK_TRUST CKT_NSS_TRUSTED_DELEGATOR
on some of the Mozilla-originating certificates
2. half of the file consisting of newly added certificates with a comment
# Microsoft Code Signing Only Certificate
trusted for code signing alone.
diff -U0 upstream-3.79.txt certdata-fedora.txt | grep CKA_TRUST | sort -u
+CKA_TRUST_CODE_SIGNING CK_TRUST CKT_NSS_TRUSTED_DELEGATOR
+CKA_TRUST_EMAIL_PROTECTION CK_TRUST CKT_NSS_MUST_VERIFY_TRUST
+CKA_TRUST_SERVER_AUTH CK_TRUST CKT_NSS_MUST_VERIFY_TRUST
+CKA_TRUST_STEP_UP_APPROVED CK_BBOOL CK_FALSE
-CKA_TRUST_CODE_SIGNING CK_TRUST CKT_NSS_MUST_VERIFY_TRUST
Thus, for purposes other than code signing we have effectively
Mozilla's 3.79 version.
For code signing, we additionally trust an extra set of certificates,
including ones not coming from Mozilla.
The rather detailed description in
https://bugzilla.redhat.com/show_bug.cgi?id=2117793
suggests that this is an unfortunately non-transparent stop-gap
solution of sorts
to satisfy .NET code signing needs while a better approach is in the works.
Commit messages (and RPM changelog) should details the changes made to the
NSS's certdata.txt during the update. And, for the sake of traceability, the
repository, branch, tag, hg commit, from which certdata.txt was pulled
should
also be part of the commit message (and RPM changelog). (and an empty line
between commit title and the rest of the commit message would be
appreciated,
for git log --oneline usage).
That'd be great.
The RPM change log and git log come from the release tools. When I
release a new version of ca-certificates, I release them on a number of
platforms (and have to deal with some rhel process). Unfortunately it
means that it wasn't easy to add this kind of change to the actual
checking on all these platforms (since it was mostly automated.
It should also be noted the fetch.sh script (most notably check_certs.sh) is
doing a terrible job at reporting the changes, most notably saying already
present certificates are added.
I'd also like to suggest separating Mozilla and
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/10/22 6:29 AM, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == This is initial step to move JDKs to be more like other JDKs, to build proper transferable images, and to lower certification burden of each binary. Long storyshort, first step in: https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs This first step will move, one by one, individual JDKs in F37 to be built `--with-stdc++lib=static` and against in-tree (bundeld) libraries: `--with-zlib="bundled" --with-freetype="bundled" --with-libjpeg="bundled" --with-giflib="bundled" --withlibpng="bundled" --with-lcms="bundled" --with-harfbuzz="bundled" ` We already made a heavy testing of the behavior, and user should not face negative experience. I'm not sure if this is I'm very confused on why this reduces certification burden. In our crypto libraries this is exactly the kind of behavior we would *NOT* want packages to do because it increases our certification and support burden. bob == Owner == * Name: [[User:jvanek| Jiri Vanek]] * Email: jva...@redhat.com == Detailed Description == Please see https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs for whole picture Please see https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Move_JDKs_in_RPMs_to_become_portable for this particular step. I would rather keep the details in the main page then here. == Feedback == According to short investigations, there are already precedents, where certification is a reason to build once, certificate, and repack. According to developers, the non-portbale JDK is causing upredicted behavior different from other JDK vendors According to JDK packagers and testers, there is to much JDKs now, and the https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Move_Fedora_JDKs_to_become_single-built.2C_portable.2C_ordinary_JDKs.2C_while_keeping_comfortable.2C_usual_system_integration is the only way out == Benefit to Fedora == Please see https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Motivation for whole picture. This particular proposal's main benefit will be that Fedora's JDKs as packed in RPMs will again start to resemble upstream JDKs and other vendors build, and some platform specific issues disappear, while JDKs remain same in view of system integration and user experience == Scope == * Proposal owners: push improved version of https://src.fedoraproject.org/rpms/java-latest-openjdk/pull-request/98#request_diff to all JDKs - one by one from latest, over 17 to 11 and 8. Once settled down in F37 the backport to F36 is expected. * Other developers: really, nothing. If there will be unexpected impact to other developers, the https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs may need rework * Release engineering: N/A [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == The compatibility and upgrade path should remain completely smooth. == How To Test == Install system JDK (java-17-openjdk) and ru your favorite application or development. No regression should be noted. == User Experience == Because of in-tree libraries, minimal image or font rendering differences canbe spotted after very detailed investigations - https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Side_effects - still, no of th e https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Known_issues should be hit by this proposal. == Dependencies == No dependent packages should notice the change. == Contingency Plan == * Contingency mechanism: Revert the patches and rework https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs * Contingency deadline: before f37 release * Blocks release? Unless the java-stack will become completely borked then no. == Documentation == https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ___ 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: Landing a larger-than-release change (distrusting SHA-1 signatures)
On 3/9/22 1:56 AM, Daniel P. Berrangé wrote: On Wed, Mar 09, 2022 at 10:46:21AM +0100, Alexander Sosedkin wrote: On Wed, Mar 9, 2022 at 10:20 AM Daniel P. Berrangé wrote: On Tue, Mar 08, 2022 at 07:40:15PM +0100, Alexander Sosedkin wrote: We've been disabling it in TLS, but its usage is much wider than TLS. The next agonizing step is to restrict its usage for signatures on the cryptographic libraries level, with openssl being the scariest one. Good news is, RHEL-9 is gonna lead the way and thus will take a lot of the hits first. Fedora doesn't have to pioneer it. Bad news is, Fedora has to follow suit someday anyway, and this brings me to how does one land such a change. --- Fedora is a large distribution with short release cycles, and the only realistic way to weed out its reliance on SHA-1 signatures from all of its numerous dark corners is to break them. Make creation and verification fail in default configuration. But it's unreasonable to just wait for, say, Fedora 37 branch-off and break it in Rawhide for Fedora 38. The fallout will just be too big. If RHEL-9 has lead the way, what are the stats for real world RHEL impact ? We'll know when the real world starts using RHEL-9 en masse? What is/was the absolute number of packages and % number of packages from the RHEL distro that saw breakage ? Does preventing the distro from installing altogether count as 100%? If yes, 100%. =) Jokes aside, I can't give you an accurate estimate yet. Perhaps a useful first step is to just modify the three main crypto libs (gnutls, openssl, and nss) to send a scary warnihg message to stderr/syslog any time they get use of SHA1 in a signature. Leave that active for a release cycle and see how many bug reports we get. To be clear, the actual mechanism to turn off SHA1 for signatures doesn't involve any changes to any of our crypto libraries, it involves changing the crypto policies file. With crypto policies, you can actually turn off almost any algorithm involved in SSL or signatures in all of our libraries. There is really no good way to 'log' from the crypto libraries. Actually I think that provides a way forward that might work. 1) in fedora 37, provide a policy that turns SHA-1 off. in our testing, we encourage people to run with that policy and write bugs against components. 2) in fedora 38, SHA-1 gets turned of in the default policy and ships that way. Things that still fail would only work once in the legacy policy. 3) some day in the future (fedora 39?) it gets turned off legacy as well. bob ___ 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: How to handle ABI breakage in Rawhide
On 12/6/21 7:11 PM, Kevin Kofler via devel wrote: Florian Weimer wrote: That's not actually true, though, and it does not make much sense. If upstream commits to an ABI, versioning is not even required technically. Hardly any upstream actually commits to an ABI *forever*. Even if the ABI has not changed for 10 years, that does not mean that at some point a new ABI will not be implemented. Even glibc has a soversion (which has not changed for years, but it has one). Upstream NSS commits to changing the major version number (which is included in the library name) if it were to change the ABI. ABI breaks are fixed upstream when they occur, and there is a CI abi scanner which runs on all upstream commits to identify ABI issue. The current ABI has been stable for 2 decades now. I don't know of any other package that maintains that level of commitment. bob Kevin Kofler ___ 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: Thunderbird with mail.corp.redhat.com does not work on Fedora 33
On 10/1/20 11:05 AM, Simo Sorce wrote: On Thu, 2020-10-01 at 14:01 -0400, Simo Sorce wrote: On Thu, 2020-10-01 at 19:47 +0200, Miro Hrončok wrote: On 01. 10. 20 19:20, Simo Sorce wrote: and the policy affects all software on the system, not just thunderbird ... Is it possible to workaround the problem in Thunderbird only? Only if thunderbrind provides a configuration option to set it and then instructs NSS, afaik. CCing Bob, in case he knows of other ways. Adding back context for Bob, this is about enabling 1024 DH, because some IMAP servers are still badly configured ... I initially handled this by turning off DHE ciphers. goto thunderbird advanced tab, click on the config editior, type dhe in the search change security.ssl3.dhe_rsa_aes_128_sha and security.ssl3.dhe_rsa_aes_256_sha to false. Now you can connect thunderbird you a faulty configured server, without loosing the other protections you get with the DEFAULT policy. Your browser will still fail on those websites (though you can fix that with the same trick for firefox). While application can, in theory, override policy, almost no application do (and thunderbird is no exception). bob The q. is if this can be done exclusively for thunderbird instead of changing the system crypto policy for all TLS applications. Simo. ___ 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: RFC7919 Diffie-Hellman parameters in Fedora
On 8/22/20 7:26 PM, Kevin Kofler wrote: Christopher Engelhard wrote: tl;dr should we make it easier/automatic for users to use the Diffie-Hellman parameters defined in RFC7919? While I understand the motivation behind the RFC (interoperability, safety against intentionally or unintentionally bad parameters), hardcoded parameters sound suspicious to me. How do we know that these are not chosen to allow the NSA or some other country's equivalent agency to decrypt the conversation? TL/DR: Most "randomly" chosen values for primes today are known to be subject to small group attacks. Getting this right is difficult (which I'll demonstrate below). The chosen primes were vetted by the TLS working group based on physical constants and a generation scheme that has the required safe criteria. That is these values meet the requirements that we already know. We can all recheck them. The chances that the NSA has an attack, that happens to work on primes that someone else (IETF) generated, and doesn't work on all DH primes is pretty unlikely. As simo says, If you are worried, don't use DH. If you aren't using one of these primes, your DH connection is probably vulnerable to active attacks. Longer explanation: In order to do DH safely, you need to make sure that the public key you are provided is in a large subgroup. This can be checked in the following ways: * The prime 'P' is a safe prime (sometimes incorrectly called a strong prime. This means the p is prime and (p-1)/2 is prime (in this case (p-1)/2 is called a Sofie-germaine prime). o You check p is prime, and (p-1)/2 is prime. This is expensive for a random prime. o You check that the public key y is < p, and != 0, 1, or -1 mod p. This check is very fast. * The prime 'P is not a safe prime, but you know a large prime 'q' which is a factor of (p-1). o You check that p is prime, and q is prime. o You check that y^q mod p == 1 o You check y != 1 or -1 If you precheck known 'P' values you can skip the very expensive prime checks (because we've already checked those values and they are known to be good). To make matters worse, It's very expensive to generate a safe prime for large prime values. If you search the internet about how to do this, they well give you instructions on how to generate a non-safe prime with large q, but none of our common protocols include a q value, which means you cannot do either the prime check or the y^q mod p ==1 check, and thus a man in the middle attacker can supply a q that falls in a small subgroup and eaves-drop on your connection. TLS 1.3 allows you to only connect if the server is using a known prime, which has already been vetted as a safe prime. If you aren't using and requiring these primes, you basically have the following choices: 1) use RSA and loose PFS. 2) use ECDH (which will likely fall to quantum computers first). Since Quantum computers will ultimately remove PFS, ECDH is probably your best bet. But then you are again trusting in fixed sets of Curves that came from somewhere, and if you are paranoid about the NSA, well ___ 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: Fedora 33 System-Wide Change proposal: Make nano the default editor
On 6/25/20 12:58 PM, Jonathan Wakely wrote: Anyway, I find it hard to believe that serious developers are unable/unwilling to set their own choice of EDITOR. A systemwide default EDITOR=nano shouldn't cause them any real difficulty. I second that. I'm the guy who gets annoyed at non-vi editors because I tend to fill files in them with hjkl's due to muscle memory of 40 years of vi usage. You'll pull vi out of my cold dead hands. I'm still quite capable of setting $EDITOR in my own startup files. Pretty much anyone that has figured out and prefers vi (or emacs or whatever) knows how to set $EDITOR. bob ___ 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: dropping NSS DBM format support in F33+
On 6/11/20 8:37 AM, Robert Relyea wrote:
On 4/23/20 11:16 AM, Brian C. Lane wrote:
On Wed, Apr 22, 2020 at 10:11:25AM +0200, Daiki Ueno wrote:
Hello,
I am not sure if this deserves a Fedora Change proposal, so I'd like to
hear any opinions first before proceeding with the process.
NSS (the crypto library used by Firefox) historically supports 2
database formats: SQLite and DBM. The latter is considered legacy and
we switched the default database format to SQLite in F28[1]. Since then
I presume most of the applications have switched to the new format.
Therefore we are planning to phase out the support of DBM, targetting
F33+.
How will that effect people who have been upgrading since before F28?
Will the DBM database be transitioned to SQLite (or has it already)?
It depends on how the database was used. NSS automatically updates to
the new format if:
1) the database is opened R/W, and
2) the user has authenticated to the database (logged into to it). If
the database has no password, then only (1) is required.
Most use cases will, most likely, have caused the above changes.
Firefox would have triggered a login anytime the user first needs to
access tha master password list. Thunderbird and servers would have
triggered those conditions when the certificate was renewed.
If you aren't sure, you can manually force an update on any fedora
version before F33 with the following command:
certutil -K -X -d {directory_of_nss_database}
If you are running on a system pre-F28, you need to add sql: before the
{directory_of_nss_database}. This should work on any system built since
2005.
and supply the password when prompted.
bob
___
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
___
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: dropping NSS DBM format support in F33+
On 4/23/20 11:16 AM, Brian C. Lane wrote:
On Wed, Apr 22, 2020 at 10:11:25AM +0200, Daiki Ueno wrote:
Hello,
I am not sure if this deserves a Fedora Change proposal, so I'd like to
hear any opinions first before proceeding with the process.
NSS (the crypto library used by Firefox) historically supports 2
database formats: SQLite and DBM. The latter is considered legacy and
we switched the default database format to SQLite in F28[1]. Since then
I presume most of the applications have switched to the new format.
Therefore we are planning to phase out the support of DBM, targetting
F33+.
How will that effect people who have been upgrading since before F28?
Will the DBM database be transitioned to SQLite (or has it already)?
It depends on how the database was used. NSS automatically updates to
the new format if:
1) the database is opened R/W, and
2) the user has authenticated to the database (logged into to it). If
the database has no password, then only (1) is required.
Most use cases will, most likely, have caused the above changes. Firefox
would have triggered a login anytime the user first needs to access tha
master password list. Thunderbird and servers would have triggered
those conditions when the certificate was renewed.
If you aren't sure, you can manually force an update on any fedora
version before F33 with the following command:
certutil -K -X -d {directory_of_nss_database}
and supply the password when prompted.
bob
___
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: Fedora 34 System-Wide Change proposal: NSS CK_GCM_PARAMS change
Oops, this reply was supposed to be a "reply list" rather than a "reply". I've incorporated most of your feedback into the Change page now. Thanks. bob On 5/29/20 12:23 AM, Zbigniew Jędrzejewski-Szmek wrote: On Thu, May 28, 2020 at 03:46:25PM -0400, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/NssGCMParams == Summary == Because of changes to the PKCS #11 spec in PKCS #11 v3.0, NSS needs to change the definition of CK_GCM_PARAMS in a source incompatible way. Upstream made this change in NSS 3.52. When I'm reading this description, it feels like it was written by somebody deep in the subject, but Change pages need to be accessible to a general audience, even people who don't program in C. They should be able to get the gist without having to absorb all the details. Thanks, If you don't program in C, the change has no affect on you. It's a source level incompatibility, not a binary. I'll add that to the description. It'd help if this summary mentioned that CK_GCM_PARAMS is a struct definition and that a new field was added (if I got that right) and that end programs need to adjust by changing how they do [what?]. Yup, how to adjust is described below. I'm trying to keep the summary short. == Owner == * Name: [[User:rrelyea| Bob Relyea]] * Email: rrel...@redhat.com == Detailed Description == PKCS #11 2.40 had a mismatch between the SPEC and the released header file for CK_GCM_PARAMS. The latter is controlling. We created or header based on the former. In PKCS #11 v3.0 the reconciled this, but it left us with. The new (to NSS) definition has a new field ulIvBits, which must be set correctly. This part is very hard to grok. Is the capitalized "SPEC" an abbreviation? One of the sentences ends mid-sentence. Also "must be set correctly" by whom, how? I need to fix some typos. "must be set correctly" is described below. To solve this, the NSS 3.52 headers has both definitions: CK_NSS_GCM_PARAMS is the original NSS definition and CK_GCM_PARAMS_V3 is the new (to NSS) definition. CK_GCM_PARAMS takes on one or the other based on the definition of NSS_PKCS11_2_0_COMPAT. The current NSS builds in fedora have changes the sense of this #define to NSS_PKCS11_3_0_STRICT to get the new behavior, and keep the old behavior by default. NSS builds will automatically switch back to the upstream default in Fedora 34. None of the changes below actually requires setting the NSS_PKCS11_3_STRICT define, though doing so can test that all but option 1 is functioning. Applications can fix this the following ways: option 1 #define NSS_PKCS11_2_0_COMPAT 1 or compile with -DNSS_PKCS11_2_0_COMPAT your app will compile and run using current and older versions of NSS, but may break on newer tokens that use the new definition (same as the previous behavior. --- option 2 rename CK_GCM_PARAMS to CK_NSS_GCM_PARAMS (this will now require nss = 3.52 to compile, but won't change based on NSS_PKCS11_2_0_COMPAT). Like option 2 it may break on newer tokens. What does "rename" mean in this context? Based on the earlier text, I thought CK_GCM_PARAMS was a structure... It is. change your instances of CK_GCM_PARAMS to CK_GCM_PARAMS_V3 -- option 3 rename CK_GCM_PARAMS to CK_GCM_PARAMS_V3 and set ulIvBits to ulIvLen*8. This will require nss >= 3.52 to compile and to run. Should run on all run tokens. - option 4 Move to PK11_AEADOp interface, which all requires nss >= 3.52 to compile and run, but it's less surprising and the dependency will be picked up automatically because you are using a new for 3.52 interface. -- Option 4 is the preferred solution. It takes advantage the the PKCS #11 v3 interface for AES_GCM while removing any PCKS #11 param structure dependency in the application. It also handles backward compatibility on older tokens and automatically detects which flavor of data structure is supported. It also would help with applications that support two or more of AES_GCM, AES_CCM, and CHACHA_POLY. == Benefit to Fedora == This change will keep fedora with the NSS upstream as well as make Fedora compliant with the official OASIS PKCS #11 spec. == Scope == * Proposal owners: NSS 3.52 has already had builds made with the reverse sense. NSS will need to be rebuilt at the start of Fedora 34. * Other developers: Developers need to choose one of these options by fedora 34 or their rebuilt packages will fail at runtime. The text from above starts repeating here? I guess I could say "see description". option 1 #define NSS_PKCS11_2_0_COMPAT 1 or compile with -DNSS_PKCS11_2_0_COMPAT your app will compile and run using current and older versions of NSS, but may break on newer tokens that use the new definition (same as the previous behavior.
Re: prelink performance gains
On 10/17/2013 06:48 AM, Jan Kratochvil wrote: On Thu, 17 Oct 2013 00:16:35 +0200, Robert Relyea wrote: prelink throws rocks at a lot of packages that have to check the integrity of the shared libraries they are using. It provides no real useful way of assisting in those tasks, It provides 'prelink -y' only for exactly that purpose. There is a bug in -y; but it does not work in some (rare) cases. https://bugzilla.redhat.com/show_bug.cgi?id=666143 Workaround of that bug is one line of code, it just has not been accepted yet. I do not know the FIPS prelink issues to be able to talk more about it. 2. FIPS isn't the only place you need to do sofware integrity checks. (see rpm). rpm uses prelink -y so it already works in most cases and the rare cases can be fixed in prelink. The problem is its maintainer Jakub has more significant work to do nowadays. I use it as well, but it causes all sorts of problems (particularly in selinux restricted apps) because it's really unfriendly for a library to exec a random program and open a pipe. One of the things that would have to be done would be either 1) provide a library call that can supply the unlinked data, or 2) provide infrastructure in prelink that can reliably update the integrity check files in a way that doesn't race the changed libraries (and in a way that makes sure only prelink changed the libraries, not someone else). Both of these are easy to get wrong. smime.p7s Description: S/MIME Cryptographic Signature -- 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: F19 DVD over size - what to drop?
Thunderbird is new? Drop it. Hardly new since I've been using it on Fedora for 8 years now. bob smime.p7s Description: S/MIME Cryptographic Signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning and retiring HAL
On 03/15/2011 01:30 PM, Andy Lawrence wrote: More packages using/tagged for hal-libs? Or perhaps just dependencies that will need to be fixed. coolkey Coolkey depends on pcsc-lite (see below). pcsc-lite pcsc-lite-ccid Kalev just fixed these two in rawhide by updating to 1.7.0 smime.p7s Description: S/MIME Cryptographic Signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updating SSL keys on fedoraproject.org 2011-03-10
On 03/10/2011 09:17 AM, Stephen John Smoogen wrote: On Thu, Mar 10, 2011 at 01:07, Petr Pisar ppi...@redhat.com wrote: On 2011-03-10, Stephen Smoogen smo...@gmail.com wrote: We have already updated fedorahosted.org and will now be updating the cert for the main site: fedoraproject.org. The old certificate came from Equifax, was a 1024 bit key and had the fingerprint: [...] The new certificate is issued by GeoTrust, Inc and is a 4096 bit key with the fingerprint: Key length is not everything. Didn't you forget to upgrade hash algorithm? Sticking on SHA-1 that's been abandoned by ETSI and other authorities does not look most safely. From my research to use the SHA-2 in TLS requires the user and server to be both able to talk TLS-1.2. From what I found at wikipedia (http://en.wikipedia.org/wiki/Transport_Layer_Security) Firefox does not support 1.2 (only Opera and IE8 do). There are more than one usage for SHA-1/SHA-2. TLS uses SHA-1 as an HMAC. SHA-1 is still strong for such use (though prudence would encourage one to move off of SHA-1 even for this operation). SHA-1 is also used in the certificate. That, in theory, doesn't require TLS 1.2, though only TLS 1.2 includes protocol to tell servers what hashing algorithms the clients support, so in a strict sense only TLS tells you whether or not it's safe to use a cert with something other than SHA-1 or MD5. Most modern browers will support SHA-2 algorithms in the certificate (even when using SSL3, to TLS 1.x). The notable exceptions is verisons of Windows older than Windows XP service patch 3, and several older phones. Many CA's are apparently starting to move SHA-256 roots this year, mostly driven by NIST standards. bob smime.p7s Description: S/MIME Cryptographic Signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
On 08/02/2010 06:06 PM, Kevin Kofler wrote: Jesse Keating wrote: Here is where you should have done a fedpkg or git push [snip] There is nothing to commit, since all the changes are already committed. The joys of DVCSes. People are NOT used to commit and push being different operations. Git is highly confusing to people who aren't git experts. Somebody has changed master since you last touched it, and you had changes on your local master that are out of sync now. First, you should do: git config --add --global push.default tracking This will make git push only attempt to push to the branch you are tracking. Then you can git push your f13 changes. git checkout master to get back to master and do a git pull --rebase to pull in the latest upstream changes and re-play your unpushed changes on top of it. Then git log to see what has happened, push if necessary. Huh? Can it get any more complicated? Ingoring the tone, I had some of the same thoughts. This is a pretty basic operation, in good old broken CVS it was a single command, there must be an easier way to make git do this, or at least as a script in fedpkg that does this operation. I'm not for going back, the list of basic operations that CVS supported were finite, I would be highly surprised if git couldn't support those operations. We just need the bits to get the non-git fedora users over the hump. bob -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FC13 nss-softokn-freebl update issues
On 06/01/2010 11:48 AM, Bill Nottingham wrote: Elio Maldonado (emald...@redhat.com) said: Not sure but I strongly suspect a change made to nss.spec to be the cause. See https://bugzilla.redhat.com/show_bug.cgi?id=596840#c7 It's due to the fact that nss-softokn-freebl (actually, *all* the nss/nspr libraires) do not fit the normal library naming, so it's not explicitly pulled for multilib. For any update or release set that's composed with a package that explicitly requires a compat arch of nss-softokn-freebl (such as glibc, libpurple, pam_pkcs11, etc.), it will get pulled in via dependency resolution. F-13 updates has none of these, so it doesn't. We could add some hacks to mash to get it pulled in, but I must ask... why do all the NSS/NSPR libraries version their libraries in the library name instead of the so version (i.e., libfreebl3.so instead of libfreebl.so.3)? Because upstream selected it's names before linux naming was anything like widespread. nss/nspr upstream was also unusual in considering binary compatibility breakage a sev 1 bug. It's expected that old apps run against new versions. One good side effect of this is there is no name colision in the libraries between Network Security Services and Name Switch Select, nor NSS's libssl3.so and openssl's libssl.so. bob smime.p7s Description: S/MIME Cryptographic Signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
orphaning ifd_egate
This package has no effective upstream. The package supports the old Schlumberger/Axalto egate token which has a built-in USB reader. This token has not been available for about 5 years. I've orphaned the package in case someone who is using the tokens still needs it. Currently there is one package with a depends on ifd-egate (esc). That packages is working on getting new builds to drop support. Once that happens I recommend removing the package altogether unless someone screams;). bob smime.p7s Description: S/MIME Cryptographic Signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
