Re: dmarc, dkim and From rewriting

Re: dmarc, dkim and From rewriting

[Mark Wielaard]

Hi,

On Fri, Sep 01, 2023 at 11:21:33AM +0200, Mark Wielaard wrote:
> On Fri, Sep 01, 2023 at 10:02:23AM +0100, Sam James via Libc-alpha wrote:
> > Florian Weimer via Libc-alpha <libc-alpha@sourceware.org> writes:
> > >
> > > Removing the From: header rewriting from the mailing lists, including
> > > libc-alpha.  With the current list configuration, “git am” often does
> > > not produce correct results.
> > 
> > Have we communicated that to the overseers though (that it's so serious
> > it's worth moving services over)?
> > Obviously there's https://sourceware.org/bugzilla/show_bug.cgi?id=29713
> > already from you, but that's not the same as "this is a showstopper".
> > 
> > I wasn't aware this was a serious blocker given b2 helps collect the
> > Reviewed-bys anyway. But I can understand it being a pain for some
> > people's workflows.
> 
> Sorry this is being resolved slowly. But as you can see in the bug
> progress is being made, we just upgraded our mailman instance again
> last week. I had requested testers a couple of months ago [1], but
> didn't get much/any response, so I thought this wasn't very urgent. I
> think we are ready to switch the list to not use From rewriting for
> lists that want that. We could test it next week?

On irc people also seemed really enthousiastic about this.  I did some
more analysis on the libc-alpha messages sent this year [*] and I
think things will work out fine. So I propose we just try it out.

Lets flip the switch (there are actually multiple switches, I'll
document them in the bug) on Wednesday 18:00 UTC. Then we can monitor
things and analyze whether things worked as expected after 48 hours at
the Overseers Open Office Hour this Friday at 18:00 UTC in #overseers
on irc.libera.chat.

That might also be a good time to discuss any other glibc service
blockers. For example, it would be great to figure out how to use
builder.sourceware.org workers for patchwork.sourceware.org testing.

Cheers,

Mark

[*] https://sourceware.org/bugzilla/show_bug.cgi?id=29713#c44

Re: dmarc, dkim and From rewriting

[Mark Wielaard]

Hi,

On Mon, Sep 04, 2023 at 10:48:39AM +0200, Mark Wielaard wrote:
> On irc people also seemed really enthousiastic about this.  I did some
> more analysis on the libc-alpha messages sent this year [*] and I
> think things will work out fine. So I propose we just try it out.
> 
> Lets flip the switch (there are actually multiple switches, I'll
> document them in the bug) on Wednesday 18:00 UTC.

This is now active. The mailinglist settings are as described in
https://sourceware.org/bugzilla/show_bug.cgi?id=29713#c45

> Then we can monitor
> things and analyze whether things worked as expected after 48 hours at
> the Overseers Open Office Hour this Friday at 18:00 UTC in #overseers
> on irc.libera.chat.
> 
> That might also be a good time to discuss any other glibc service
> blockers. For example, it would be great to figure out how to use
> builder.sourceware.org workers for patchwork.sourceware.org testing.

And please feel free to drop by in #overseers whenever you like and/or
to report issues through mail or bugzilla as described at:
https://sourceware.org/mission.html#organization

Cheers,

Mark

> [*] https://sourceware.org/bugzilla/show_bug.cgi?id=29713#c44

Re: dmarc, dkim and From rewriting

[Mark Wielaard]

On Wed, Sep 06, 2023 at 08:49:40PM +0200, Mark Wielaard wrote:
> On Mon, Sep 04, 2023 at 10:48:39AM +0200, Mark Wielaard wrote:
> > On irc people also seemed really enthousiastic about this.  I did some
> > more analysis on the libc-alpha messages sent this year [*] and I
> > think things will work out fine. So I propose we just try it out.
> > 
> > Lets flip the switch (there are actually multiple switches, I'll
> > document them in the bug) on Wednesday 18:00 UTC.
> 
> This is now active. The mailinglist settings are as described in
> https://sourceware.org/bugzilla/show_bug.cgi?id=29713#c45
> 
> > Then we can monitor
> > things and analyze whether things worked as expected after 48 hours at
> > the Overseers Open Office Hour this Friday at 18:00 UTC in #overseers
> > on irc.libera.chat.

In about an hour we'll evaluate this in #overseers on irc.libera.chat
Please let us know if this works/doesn't work and/or causes any mail
issues.

> > That might also be a good time to discuss any other glibc service
> > blockers. For example, it would be great to figure out how to use
> > builder.sourceware.org workers for patchwork.sourceware.org testing.
> 
> And please feel free to drop by in #overseers whenever you like and/or
> to report issues through mail or bugzilla as described at:
> https://sourceware.org/mission.html#organization
>
> > [*] https://sourceware.org/bugzilla/show_bug.cgi?id=29713#c44

Every second Friday of the month is the Sourceware Overseers Open
Office hour in #overseers on irc.libera.chat from 18:00 till 19:00
UTC. That is today Friday September 8th.

Please feel free to drop by with any Sourceware services and hosting
questions. We will be evaluating switching off From rewriting for the
glibc libc-alpha list to see if other Sourceware mailinglist can adopt
that.

Feedback and questions about the Sourceware 25 Roadmap are also very
appreciated. https://sourceware.org/sourceware-25-roadmap.html

Of course you are welcome to drop into the #overseers channel at any
time and we can also be reached through email and bugzilla:
https://sourceware.org/mission.html#organization

If you aren't already and want to keep up to date on Sourceware
infrastructure services then please also subscribe to the overseers
mailinglist. https://sourceware.org/mailman/listinfo/overseers

We are also on the fediverse these days:
https://fosstodon.org/@sourceware

Re: [Action Required] glibc decision to use CTI services.

[Alexandre Oliva]

[adding libc-alpha, where GNU libc discussions are held]

On Aug 29, 2023, "Carlos O'Donell" <carlos@redhat.com> wrote:

> I propose the glibc project migrate to services provided by the 
> Core Toolchain Infrastructure (CTI) project, particularly services
> provided by the Linux Foundation IT team.

Nay.  I do not perceive any benefits to GNU's values in becoming
technologically dependent on an organization that never shared GNU's
values, that has constantly pretended GNU didn't exist, persistently
claimed our work to itself, and promotes and operates under values that
conflict deeply with those that GNU stands for.  It would amount to
shooting itself in the paws.

I acknowledge that the present supplier of equivalent services also
started in a hostile manner, but at this point it's the devil we know.

The plan should IMHO be to mitigate that dependency, not introduce
another or replace one with a worse one.

As I suggested back when this idea was first raised (and AFAICT there
have been no attempts to dispute that this would be a better path to
pursue), I'd be happy to accept this sort of contribution to GNU *iff*
the services were *actively* *replicated* among two or three separate
suppliers, so as to reduce the risk of dependency and of corrupting
pressure on us.

Even then, this would IMHO be a move for GNU to decide, or at the very
least be consulted on, according to its own values and priorities,
something that all mantainers appointed by GNU, myself included,
committed ourselves to observe, prioritize and uphold as maintainers of
GNU packages.  I encourage other maintainers to justify their responses
based on GNU's values and priorities, as they understand them.

-- 
Alexandre Oliva, happy hacker                    https://FSFLA.org/blogs/lxo/
   Free Software Activist                           GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice but
very few check the facts.  Think Assange & Stallman.  The empires strike back

Re: [Action Required] glibc decision to use CTI services.

[Joseph Myers]

On Wed, 30 Aug 2023, Alexandre Oliva wrote:

> Even then, this would IMHO be a move for GNU to decide, or at the very
> least be consulted on, according to its own values and priorities,
> something that all mantainers appointed by GNU, myself included,
> committed ourselves to observe, prioritize and uphold as maintainers of
> GNU packages.  I encourage other maintainers to justify their responses
> based on GNU's values and priorities, as they understand them.

I believe the LF has already agreed to implement the hosting entirely with 
free software.  Naturally we should make sure that other requirements from 
https://www.gnu.org/software/repo-criteria.en.html such as "Does not 
discriminate against classes of users, or against any country. (C2)" and 
"Permits access via Tor (we consider this an important site function). 
(C3)" are met, though I don't expect problems there.  Several criteria are 
trivally met or inapplicable simply because they concern things that are 
beyond the scope of this proposed hosting (for example, recommending 
particular choices of license, or offering choices of license, is entirely 
outside the scope of what these hosting facilities do, just as it's 
outside the scope of what Sourceware does - those are criteria for 
general-purpose hosting sites that anyone might add a package to).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [Action Required] glibc decision to use CTI services.

[Paul Eggert]

On 2023-08-30 10:31, Joseph Myers wrote:
> I believe the LF has already agreed to implement the hosting entirely with
> free software.

Where is this agreement written down? I didn't see it in the URLs 
mentioned at the start of this thread.

Too often it is tempting to use non-free software in these enterprises, 
and we need to have an agreement and a commitment about an enforcement 
mechanism that detects and repairs things if somebody falls victim to 
this temptation (and of course that guides people away from succumbing 
to the temptation in the first place). This detection and enforcement 
mechanism has to be usable by glibc software contributors and 
maintainers, not just by the CTI providers.

As I'm new to this (I just read yesterday that a decision is wanted by 
today) I'll vote NAY until I see something more binding about this 
important issue.


> Naturally we should make sure that other requirements from 
> https://www.gnu.org/software/repo-criteria.en.html ...  are met, though I don't expect problems there.

Although I don't expect problems either, I'd like to see this written 
down as well.

Re: [Action Required] glibc decision to use CTI services.

[Sam James]

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 2023-08-30 10:31, Joseph Myers wrote:
>> I believe the LF has already agreed to implement the hosting entirely with
>> free software.
>
> Where is this agreement written down? I didn't see it in the URLs
> mentioned at the start of this thread.
>
> Too often it is tempting to use non-free software in these
> enterprises, and we need to have an agreement and a commitment about
> an enforcement mechanism that detects and repairs things if somebody
> falls victim to this temptation (and of course that guides people away
> from succumbing to the temptation in the first place). This detection
> and enforcement mechanism has to be usable by glibc software
> contributors and maintainers, not just by the CTI providers.
>
> As I'm new to this (I just read yesterday that a decision is wanted by
> today) I'll vote NAY until I see something more binding about this
> important issue.
>

It's still unclear to me what problems this will solve compared to
using sourceware.

As far as I've seen, the sourceware overseers handle requests
promptly. Is there something we've asked them to do which they've
been unable to fulfill?

thanks,
sam

Re: [Action Required] glibc decision to use CTI services.

[Florian Weimer]

* Sam James via Libc-alpha:

> As far as I've seen, the sourceware overseers handle requests
> promptly. Is there something we've asked them to do which they've
> been unable to fulfill?

Removing the From: header rewriting from the mailing lists, including
libc-alpha.  With the current list configuration, “git am” often does
not produce correct results.

Thanks,
Florian

Re: [Action Required] glibc decision to use CTI services.

[Sam James]

Florian Weimer via Libc-alpha <libc-alpha@sourceware.org> writes:

> * Sam James via Libc-alpha:
>
>> As far as I've seen, the sourceware overseers handle requests
>> promptly. Is there something we've asked them to do which they've
>> been unable to fulfill?
>
> Removing the From: header rewriting from the mailing lists, including
> libc-alpha.  With the current list configuration, “git am” often does
> not produce correct results.

Have we communicated that to the overseers though (that it's so serious
it's worth moving services over)? Obviously there's https://sourceware.org/bugzilla/show_bug.cgi?id=29713
already from you, but that's not the same as "this is a showstopper".

I wasn't aware this was a serious blocker given b2 helps collect the
Reviewed-bys anyway. But I can understand it being a pain for some
people's workflows.

thanks,
sam

dmarc, dkim and From rewriting

[Mark Wielaard]

Hi,

On Fri, Sep 01, 2023 at 10:02:23AM +0100, Sam James via Libc-alpha wrote:
> Florian Weimer via Libc-alpha <libc-alpha@sourceware.org> writes:
> > * Sam James via Libc-alpha:
> >
> >> As far as I've seen, the sourceware overseers handle requests
> >> promptly. Is there something we've asked them to do which they've
> >> been unable to fulfill?
> >
> > Removing the From: header rewriting from the mailing lists, including
> > libc-alpha.  With the current list configuration, “git am” often does
> > not produce correct results.
> 
> Have we communicated that to the overseers though (that it's so serious
> it's worth moving services over)?
> Obviously there's https://sourceware.org/bugzilla/show_bug.cgi?id=29713
> already from you, but that's not the same as "this is a showstopper".
> 
> I wasn't aware this was a serious blocker given b2 helps collect the
> Reviewed-bys anyway. But I can understand it being a pain for some
> people's workflows.

Sorry this is being resolved slowly. But as you can see in the bug
progress is being made, we just upgraded our mailman instance again
last week. I had requested testers a couple of months ago [1], but
didn't get much/any response, so I thought this wasn't very urgent. I
think we are ready to switch the list to not use From rewriting for
lists that want that. We could test it next week?

Cheers,

Mark

[1] https://inbox.sourceware.org/libc-alpha/Y2GocuarFslwvb9j@wildebeest.org/

Re: dmarc, dkim and From rewriting

[Florian Weimer]

* Mark Wielaard:

> Sorry this is being resolved slowly. But as you can see in the bug
> progress is being made, we just upgraded our mailman instance again
> last week. I had requested testers a couple of months ago [1], but
> didn't get much/any response, so I thought this wasn't very urgent. I
> think we are ready to switch the list to not use From rewriting for
> lists that want that. We could test it next week?

> [1] https://inbox.sourceware.org/libc-alpha/Y2GocuarFslwvb9j@wildebeest.org/

I read <https://sourceware.org/bugzilla/show_bug.cgi?id=29713#c35>
and comments in the vicinity as expressing a desire not to make the
change (i.e., keep From: header rewriting) for compatibility with
DKIM defaults in certain widely deploy free software MTAs.

Thanks,
Florian