Here is a list of things I would like to propose for Fedora 25:
Split all NSS modules into separate packages, except nss_files and nss_dns. This will make it eventually possible to deprecate nss_hesiod, and build nss_nis and nss_nisplus against libtirpc instead of the built-in RPC library.
Remove dns from the networks service in /etc/nsswitch.conf. Hardly anyone needs it, and the implementation is quite broken anyway. It just increases attack surface needlessly.
Build rawhide *and* the f25 branch with assertions enabled.
Use a single statically linked binary for sln and ldconfig.
Florian
On 03/29/2016 03:19 AM, Florian Weimer wrote:
Here is a list of things I would like to propose for Fedora 25:
OK.
Split all NSS modules into separate packages, except nss_files and nss_dns. This will make it eventually possible to deprecate nss_hesiod, and build nss_nis and nss_nisplus against libtirpc instead of the built-in RPC library.
This sounds good.
Remove dns from the networks service in /etc/nsswitch.conf. Hardly anyone needs it, and the implementation is quite broken anyway. It just increases attack surface needlessly.
Could you expand on this a bit more?
Build rawhide *and* the f25 branch with assertions enabled.
Agreed.
Use a single statically linked binary for sln and ldconfig.
Agreed.
The F25 schedule has been accelerated:
https://fedoraproject.org/wiki/Releases/25/Schedule
Which means F25 will have to ship with glibc 2.23, there will be no way we can get 2.24 into a stable shape by then. glibc 2.24 has an intended release of February 2017.
So any changes we make must be strictly cosmetic, and the above changes you mention seem in that sort of category e.g. preparing for further changes in later releases.
Could you go ahead and create *one* change request page which covers all of these:
(a) Update to glibc 2.23.1 stable branch.
(b) NSS subpackaging.
(c) Enabling assertions.
(d) Statically linking sln/ldconfig
I'd call it:
https://fedoraproject.org/wiki/Changes/GLIBC223_F25_Update
For a template I'd used:
https://fedoraproject.org/wiki/Changes/GLIBC223
On 03/29/2016 10:02 PM, Carlos O'Donell wrote:
Remove dns from the networks service in /etc/nsswitch.conf. Hardly anyone needs it, and the implementation is quite broken anyway. It just increases attack surface needlessly.
Could you expand on this a bit more?
In /etc/nsswitch.conf, change:
networks: files dns
to:
networks: files
Could you go ahead and create *one* change request page which covers all of these:
(a) Update to glibc 2.23.1 stable branch.
Aren't we going to do that throughout F24 anyway?
Florian
On 03/30/2016 01:03 AM, Florian Weimer wrote:
On 03/29/2016 10:02 PM, Carlos O'Donell wrote:
Remove dns from the networks service in /etc/nsswitch.conf. Hardly anyone needs it, and the implementation is quite broken anyway. It just increases attack surface needlessly.
Could you expand on this a bit more?
In /etc/nsswitch.conf, change:
networks: files dns
to:
networks: files
OK, but to be clear we would leave all the code in place for users that want to add it back, we would only be removing it in the default configuration?
I'm fine with that.
Could you go ahead and create *one* change request page which covers all of these:
(a) Update to glibc 2.23.1 stable branch.
Aren't we going to do that throughout F24 anyway?
One hopes :-)
We should list it in F25 just to be clear and in the event we don't get to it. Plan for the worst, hope for the best.
On 03/30/2016 10:58 PM, Carlos O'Donell wrote:
On 03/30/2016 01:03 AM, Florian Weimer wrote:
On 03/29/2016 10:02 PM, Carlos O'Donell wrote:
Remove dns from the networks service in /etc/nsswitch.conf. Hardly anyone needs it, and the implementation is quite broken anyway. It just increases attack surface needlessly.
Could you expand on this a bit more?
In /etc/nsswitch.conf, change:
networks: files dns
to:
networks: files
OK, but to be clear we would leave all the code in place for users that want to add it back, we would only be removing it in the default configuration?
Yes, it's just a configuration change.
Could you go ahead and create *one* change request page which covers all of these:
(a) Update to glibc 2.23.1 stable branch.
Aren't we going to do that throughout F24 anyway?
One hopes :-)
We should list it in F25 just to be clear and in the event we don't get to it. Plan for the worst, hope for the best.
Okay. Do we have to do anything special once F25 branches, so that it's based of F24 and not rawhide?
Florian
On 03/31/2016 03:16 AM, Florian Weimer wrote:
We should list it in F25 just to be clear and in the event we don't get to it. Plan for the worst, hope for the best.
Okay. Do we have to do anything special once F25 branches, so that it's based of F24 and not rawhide?
I had not considered the ABI implications of F25 needing to be behind rawhide in terms of ABI.
This is going to be more treacherous than I thought.
If we want Rawhide to tracker master, and we do, then when F25 branches we need to go backwards in time to 2.23.1, reversing any ABI changes that were made in 2.24.90 development.
I'm not sure how we're going to handle this, or if Fedora even understands how carefully Fedora release cycles were synchronized with glibc release cycles to avoid this.
The options as I see it are:
(a) Fedora Rawhide stops tracking upstream master, and is updated only when glibc releases happen.
(b) Fedora Rawhide is rolled back to 2.23.1 before F25 branches and libabigail is used to do an ABI diff between F25 and the rollback, any significant ABI changes are analyzed and a mass rebuild requested if it's required.
I think we need to reach out to fedora-devel and start a discussion that basically says:
"The accelerated F25 schedule means we are out of sync with upstream glibc release and ABI guarantees. As such the F25 release may or may not require a mass rebuild depending on the ABI differences that have accumulated in Fedora Rawhide. Worst case we need to plan for a mass rebuild in F25, best case, we don't."
Shucks what a mess.
On 03/31/2016 02:49 PM, Carlos O'Donell wrote:
On 03/31/2016 03:16 AM, Florian Weimer wrote:
We should list it in F25 just to be clear and in the event we don't get to it. Plan for the worst, hope for the best.
Okay. Do we have to do anything special once F25 branches, so that it's based of F24 and not rawhide?
I had not considered the ABI implications of F25 needing to be behind rawhide in terms of ABI.
This is going to be more treacherous than I thought.
If we want Rawhide to tracker master, and we do, then when F25 branches we need to go backwards in time to 2.23.1, reversing any ABI changes that were made in 2.24.90 development.
I'm not sure how we're going to handle this, or if Fedora even understands how carefully Fedora release cycles were synchronized with glibc release cycles to avoid this.
The options as I see it are:
(a) Fedora Rawhide stops tracking upstream master, and is updated only when glibc releases happen.
For this release, yes. Future releases can go back to tracking upstream master.
(b) Fedora Rawhide is rolled back to 2.23.1 before F25 branches and libabigail is used to do an ABI diff between F25 and the rollback, any significant ABI changes are analyzed and a mass rebuild requested if it's required.
There isn't going to be a mass rebuild for F25 per previous communications.
libabigail isn't powerful enough for this because the ABI impact can be extremely subtle, especially for static libraries.
I think we need to reach out to fedora-devel and start a discussion that basically says:
"The accelerated F25 schedule means we are out of sync with upstream glibc release and ABI guarantees. As such the F25 release may or may not require a mass rebuild depending on the ABI differences that have accumulated in Fedora Rawhide. Worst case we need to plan for a mass rebuild in F25, best case, we don't."
*shrug* The answer will be that we shouldn't put non-releasable stuff in rawhide, and that wouldn't even be wrong.
Florian
On 03/31/2016 09:02 AM, Florian Weimer wrote:
"The accelerated F25 schedule means we are out of sync with upstream glibc release and ABI guarantees. As such the F25 release may or may not require a mass rebuild depending on the ABI differences that have accumulated in Fedora Rawhide. Worst case we need to plan for a mass rebuild in F25, best case, we don't."
*shrug* The answer will be that we shouldn't put non-releasable stuff in rawhide, and that wouldn't even be wrong.
I've filed a FESCo ticket regarding this:
https://fedorahosted.org/fesco/ticket/1565
I've asked upstream if an August 1st hard deadline is OK:
https://www.sourceware.org/ml/libc-alpha/2016-03/msg00766.html
That would give us one week from release to Alpha Freeze to do a final merge of glibc to include the 2.24 release updates.
It seems like that should work, but only if we don't slip.
On Thu, Mar 31, 2016 at 03:02:30PM +0200, Florian Weimer wrote:
On 03/31/2016 02:49 PM, Carlos O'Donell wrote:
(b) Fedora Rawhide is rolled back to 2.23.1 before F25 branches and libabigail is used to do an ABI diff between F25 and the rollback, any significant ABI changes are analyzed and a mass rebuild requested if it's required.
There isn't going to be a mass rebuild for F25 per previous communications.
There is a mass rebuild scheduled around early July just before the F25 branch point according to the schedule: https://fedoraproject.org/wiki/Releases/25/Schedule
Cheers,
Mark
On 03/31/2016 03:34 PM, Siddhesh Poyarekar wrote:
On Wed, Mar 30, 2016 at 07:03:02AM +0200, Florian Weimer wrote:
In /etc/nsswitch.conf, change:
networks: files dns
to:
networks: files
Why do you think nobody uses DNS?
The implementation is currently quite broken, and we have not received a bug report about the lack of CNAME support.
Note that's about the networks database, not the hosts database.
Florian
On Thu, Mar 31, 2016 at 03:44:45PM +0200, Florian Weimer wrote:
The implementation is currently quite broken, and we have not received a bug report about the lack of CNAME support.
Note that's about the networks database, not the hosts database.
Ahh OK, I overlooked that.
Siddhesh
On Tue, Mar 29, 2016 at 09:19:14AM +0200, Florian Weimer wrote:
Here is a list of things I would like to propose for Fedora 25:
Split all NSS modules into separate packages, except nss_files and nss_dns. This will make it eventually possible to deprecate nss_hesiod, and build nss_nis and nss_nisplus against libtirpc instead of the built-in RPC library.
Remove dns from the networks service in /etc/nsswitch.conf. Hardly anyone needs it, and the implementation is quite broken anyway. It just increases attack surface needlessly.
Build rawhide *and* the f25 branch with assertions enabled.
Use a single statically linked binary for sln and ldconfig.
Another thing I've thought of for a while, enabling sanitizer options in glibc. Not in glibc itself, but to build separate packages (glibc-sanitize, glibc-devel-sanitize, etc.) that can replace glibc if one wants to do that for testing. We only enable generation of this in rawhide.
Siddhesh
On Fri, Apr 01, 2016 at 11:15:47AM +0530, Siddhesh Poyarekar wrote:
Another thing I've thought of for a while, enabling sanitizer options in glibc. Not in glibc itself, but to build separate packages (glibc-sanitize, glibc-devel-sanitize, etc.) that can replace glibc if one wants to do that for testing. We only enable generation of this in rawhide.
Oh, and of course, tunables :)
Siddhesh
On 03/29/2016 09:19 AM, Florian Weimer wrote:
Remove dns from the networks service in /etc/nsswitch.conf. Hardly anyone needs it, and the implementation is quite broken anyway. It just increases attack surface needlessly.
I was mistaken, it is already not there. I must have added it manually for testing.
Florian
I created the wiki page for this Fedora Change:
https://fedoraproject.org/wiki/Changes/GLIBC224
It would be great if you could double-check that everything is in order.
Thanks, Florian
On 05/23/2016 01:36 PM, Florian Weimer wrote:
I created the wiki page for this Fedora Change:
https://fedoraproject.org/wiki/Changes/GLIBC224
It would be great if you could double-check that everything is in order.
Looks good to me. Thanks for setting up the page!
On 06/01/2016 02:29 AM, Carlos O'Donell wrote:
On 05/23/2016 01:36 PM, Florian Weimer wrote:
I created the wiki page for this Fedora Change:
https://fedoraproject.org/wiki/Changes/GLIBC224
It would be great if you could double-check that everything is in order.
Looks good to me. Thanks for setting up the page!
Thanks, I marked it as ready for the wrangler.
Florian
-
Carlos O'Donell -
Florian Weimer -
Mark Wielaard -
Siddhesh Poyarekar