2:19 a.m.
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
3:02 p.m.
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
--
Cheers,
Carlos.
12:03 a.m.
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
3:58 p.m.
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.
--
Cheers,
Carlos.
2:16 a.m.
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
7:49 a.m.
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.
--
Cheers,
Carlos.
8:02 a.m.
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
9:28 a.m.
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.
--
Cheers,
Carlos.
11:45 a.m.
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
8:44 a.m.
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
9:07 a.m.
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
12:45 a.m.
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
12:46 a.m.
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
2:56 a.m.
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
12:36 p.m.
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
7:29 p.m.
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!
--
Cheers,
Carlos.
2:21 a.m.
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
2887
days inactive
2951
days old
17 comments
4 participants
participants (4)
-
Carlos O'Donell -
Florian Weimer -
Mark Wielaard -
Siddhesh Poyarekar