Fwd: Hurd Security vulnerabilities, please upgrade!

Fwd: Hurd Security vulnerabilities, please upgrade!

[jbranso]

[-- Attachment #1: Type: text/plain, Size: 738 bytes --]

So this email from the Hurd developers just came through about recent GNU/Hurd
vunerabilities.  :)

-------- Forwarded message -------
From: "Samuel Thibault" <sthibault@debian.org>
To: debian-hurd@lists.debian.org, hurd-bug@gnu.org
Sent: August 9, 2021 10:04 PM
Subject: Hurd Security vulnerabilities, please upgrade!
Hello,

In the past months, Sergey Bugaev has been working on fixing some
Hurd security vulnerabilities. This is now fixed in the latest Debian
packages, so please upgrade and reboot!

hurd >= 1:0.9.git20210404-9
libc0.3 >= 2.31-13+hurd.1
gnumach-image-1.8-* >= 2:1.8+git20210809-1

(A libc0.3 2.31-13+hurd.2 upload will also happen tomorrow, but that
will only be intended to fix builds)

Samuel

[-- Attachment #2: signature.asc --]
[-- Type: text/plain, Size: 849 bytes --]

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEi6MnFvk67auaclLJ5pG0tXV4H2IFAmER3joACgkQ5pG0tXV4
H2KQcQ//Yfx8v9/oYqeDtUmgbkjtFXhglqColqThFowKsRnzbJxZ4wEDMULZG7Mc
b7JNMgEaknc6xazzwbCF4ZwyOxjRbh1QOVL56cXrGj862WyUbn/tvcFJShV8/qsI
ImhsO6TBaPgQ67XJOQl/yFo7PWkXfQa8Kbv/xONClB2/aHGCfVlqJCMcQv3+vwj8
yZIvCPtLRMbeAt0yrs395o4GVI3Q6w1BnPy/yXqWLZ10QAeh5RnlCX+rU1zQEvIN
wtZa3WYqbxq4DvU3d2JkhiH7EO/tLAiKm4fU97DAQniFIdjzi63R8x1QRcw6ESEM
TUn2rG2z7eKHaM9CUHZ79XkOjQylX+2zh3dw/k9t+ktQIibil8nL0468lJ6CF6wE
WFpMAO+46RPaeUv3YZ/VSK5YnMGN2UHy82vG737zgifkn1IYcDEUggAhfTHOVLrY
2BJWRL3Bm5SBqgxVOm3PKCsr1FQOwwWe/vGsZWaqDMdcMnm08iwZMP9YOACfJaT5
oQOwn8R6tLSBcnlw9zMsVOK+bA2WPsPXWuKQEpK7TKLKNj28IoAOalgwVAMP5oS9
zo6wGv+/kWItUFzxCIeK5r7jhOd4US8WSIgb2b3P5PD4dbJ09RWorTPVDxiul45y
zQ+rXLPzmmrlZKL1LBB8Mq6l2HDwa3iY00AnE6U13UELTYgZuc0=
=CmA8
-----END PGP SIGNATURE-----

Re: Hurd Security vulnerabilities, please upgrade!

[Ricardo Wurmus]

Hi Samuel,

> In the past months, Sergey Bugaev has been working on fixing 
> some
> Hurd security vulnerabilities. This is now fixed in the latest 
> Debian
> packages, so please upgrade and reboot!

Thanks for the fixes and the heads-up!

> hurd >= 1:0.9.git20210404-9
> libc0.3 >= 2.31-13+hurd.1
> gnumach-image-1.8-* >= 2:1.8+git20210809-1

I’m a little unclear on what this means for distributions like 
Guix.  Should we just update to the latest version from git?  Are 
there specific commits we should use if it’s not just the latest?

Thanks!

-- 
Ricardo

Re: Hurd Security vulnerabilities, please upgrade!

[Samuel Thibault]

Ricardo Wurmus, le mar. 10 août 2021 17:52:34 +0200, a ecrit:
> I’m a little unclear on what this means for distributions like Guix.  Should
> we just update to the latest version from git?  Are there specific commits
> we should use if it’s not just the latest?

Since Sergey's copyright assignment is not complete yet, it's not
commited yet, so you have to pick up the patches from the debian
repository.

Samuel

Re: Hurd Security vulnerabilities, please upgrade!

[Ludovic Courtès]

Hi Samuel,

Samuel Thibault <samuel.thibault@gnu.org> skribis:

> Ricardo Wurmus, le mar. 10 août 2021 17:52:34 +0200, a ecrit:
>> I’m a little unclear on what this means for distributions like Guix.  Should
>> we just update to the latest version from git?  Are there specific commits
>> we should use if it’s not just the latest?
>
> Since Sergey's copyright assignment is not complete yet, it's not
> commited yet, so you have to pick up the patches from the debian
> repository.

It would be interesting to consider dropping the copyright assignment
requirement for Hurd/Mach/MiG.  For what remains primarily a hobby
project, this looks to me like a hindrance more than anything else.

Ludo’.

Regarding copyright assignment to FSF

[Damien Zammit]

Hi Ludo,

On 11/8/21 11:01 pm, Ludovic Courtès wrote:
> It would be interesting to consider dropping the copyright assignment
> requirement for Hurd/Mach/MiG.  For what remains primarily a hobby
> project, this looks to me like a hindrance more than anything else.

I imagine it is slightly inconvenient for new contributors, but not a hindrance in my opinion.
It ensures that FSF has complete control of the licensing.
For example, how will FSF upgrade the project to GPLv3 if multiple people hold the copyright?
(There are plans to remove the GPLv2-only code btw, as Samuel said).

PS: Why are you promoting a widespread drop of FSF copyright assignment anyway?
In my opinion, FSF is a better steward for copyright authorship than any company would be assuming
you are working on free software on an employer's time and don't mutually agree
with your employer to keep your own authorship.  Even if you do keep it yourself,
it makes it more difficult for anyone to enforce the GPL for that project.
Don't tell me GPL enforcement never happens; for example look at the situation with OpenWRT.
If anything, the lack of GPL enforcement means we need to work harder on it, not give
companies more power over our free software projects.

Damien

Re: Regarding copyright assignment to FSF

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 1852 bytes --]

Damien Zammit schreef op do 12-08-2021 om 12:18 [+1000]:
> Hi Ludo,

I'm not Ludo, but here's my response anyway.

(I'm interested in doing some small and larger things with the Hurd,
but I keep being occupied by other things and I'm having a hard time
understanding the inner workings ...)

> On 11/8/21 11:01 pm, Ludovic Courtès wrote:
> > It would be interesting to consider dropping the copyright assignment
> > requirement for Hurd/Mach/MiG.  For what remains primarily a hobby
> > project, this looks to me like a hindrance more than anything else.
> 
> I imagine it is slightly inconvenient for new contributors, but not a hindrance in my opinion.
> It ensures that FSF has complete control of the licensing.
> For example, how will FSF upgrade the project to GPLv3 if multiple people hold the copyright?
> (There are plans to remove the GPLv2-only code btw, as Samuel said).

When the code is GPLv2-or-later, replace v2 with v3 in the license notices.
If the code uses GPLv2-only code, first upgrade the GPLv2-only code to GPLv3-or-later.

Upgrading the GPLv2-only code might be dificult if multiple people hold
the copyright, so for the GPLv2-only code, it might be a good idea to still
require copyright assignment.

> PS: Why are you promoting a widespread drop of FSF copyright assignment anyway?
> In my opinion, FSF is a better steward for copyright authorship than any company
> would be assuming you are working on free software on an employer's time and don't
> mutually agree with your employer to keep your own authorship.

FWIW, Ludovic does not seem to be promoting assigning copyright to employers.

> Even if you do keep it yourself, it makes it more difficult for anyone to enforce
> the GPL for that project.

A fair point, though I don't know how accurate that is.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Regarding copyright assignment to FSF

[Samuel Thibault]

Maxime Devos, le ven. 13 août 2021 15:42:37 +0200, a ecrit:
> so for the GPLv2-only code, it might be a good idea to still
> require copyright assignment.

The GPLv2-only code is essentially the pfinet stack from Linux, for
which we don't have any assignment anyway. But again, this is getting
replaced by lwip.

Samuel

Re: Regarding copyright assignment to FSF

[Svante Signell]

On Fri, 2021-08-13 at 18:23 +0200, Samuel Thibault wrote:

> The GPLv2-only code is essentially the pfinet stack from Linux, for
> which we don't have any assignment anyway. But again, this is getting
> replaced by lwip.

Hello. 

How to make lwip by default enabled instead of pfinet?

Thanks :)

Re: Regarding copyright assignment to FSF

[Samuel Thibault]

Svante Signell, le sam. 14 août 2021 23:26:55 +0200, a ecrit:
> On Fri, 2021-08-13 at 18:23 +0200, Samuel Thibault wrote:
> 
> > The GPLv2-only code is essentially the pfinet stack from Linux, for
> > which we don't have any assignment anyway. But again, this is getting
> > replaced by lwip.
> 
> How to make lwip by default enabled instead of pfinet?

There seems to be a wiki page about it.

Samuel

Re: Regarding copyright assignment to FSF

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]


Maxime Devos <maximedevos@telenet.be> writes:

> Upgrading the GPLv2-only code might be dificult if multiple people hold
> the copyright, so for the GPLv2-only code, it might be a good idea to still
> require copyright assignment.

When we did it for Mercurial, going from GPLv2 only to or later took
years and a *lot* of work. That’s why I consider copyright assignment to
the FSF as a good idea. They still get restricted to only use that to
further Free Software (if they violate that, the assignment loses the
reliablility that they need).

>> Even if you do keep it yourself, it makes it more difficult for anyone to enforce
>> the GPL for that project.
>
> A fair point, though I don't know how accurate that is.

From what I read, it’s the most important point, because the first
answer the other sides lawyers always give is „you’re not authorized by
*all* authors to enforce the GPL, so you lose.“

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: Regarding copyright assignment to FSF

[Ivan Shmakov]

>>>>> On 2021-08-12 12:18:20 +1000, Damien Zammit wrote:
>>>>> On 11/8/21 11:01 pm, Ludovic Courtès wrote:

	This seem somewhat off-topic for the lists, so I’m open to
	suggestions on what other forum to use (should anyone wish
	to continue this thread.)  My suggestion is, as usual,
	to use a Usenet newsgroup, such as comp.misc, for the purpose.
	(See http://www.aioe.org/ for a free, no registration needed,
	IPv4-only newsserver; or http://www.eternal-september.org/ for
	free registration, IPv6 + IPv4 one.)

 >> It would be interesting to consider dropping the copyright assignment
 >> requirement for Hurd/Mach/MiG.  For what remains primarily a hobby
 >> project, this looks to me like a hindrance more than anything else.

 > I imagine it is slightly inconvenient for new contributors, but not a
 > hindrance in my opinion.

	I’m going to concur; there’s some delay, sure, but not that much
	of actual effort on the part of the new contributor.  Unless, of
	course, one’s employer is uncooperative, but I’m afraid that
	can’t be helped.

 > It ensures that FSF has complete control of the licensing.

	And enforcement.

	I’d argue that in a better world, no copyright assignment would
	be necessary (nor would be GPL, but that’s another matter), as
	anyone would be able to bring an infringement case to the court
	entirely by themselves.  As it is, however, some considerations
	apply.

	As I understand it (though IANAL), there’re two parts to this
	story.  First of all, copyright enforcement is, in general, a
	process that itself requires certain effort.  Do you have time
	to spare on filing a suit?  Will you have some more to see it
	through?  Do you know a good lawyer to hire, or do you have the
	necessary skills to represent yourself in the court?  What remedy
	will you seek?

	Moreover, /copyleft/ enforcement is tricky by itself.  Copyright
	was devised, basically, as a legal tool for author to sue his
	publisher for royalties.  As such, even though that does seem
	to slowly change, the first question of the court for your newly-
	brought GPL-infringement case would be: what sum, in your opinion,
	does the company owe you?  Are you prepared to answer that?

	Given the above, I’m inclined to think that assigning copyright
	to a party legally prepared to fight for it to be a sensible
	choice /whether it is required or not./  And /especially/ for
	hobby projects; for I presume that for something you do for
	living, you’ll be quite in position to estimate damages arising
	from someone infringing your copyright.

	From here, we may try to rank different charities on how well
	they handle their enforcement cases.  My guess is that FSF will
	come near the top.

	The other part concerns one’s employer, and the terms of the
	contract.  For instance, the contract I’m currently under says
	that I’m entitled to copyright on any and all works I create,
	/unless/ I’ve been specifically directed by the employer to
	create any given work.

	From what I’ve heard, however, some contracts allow the
	/employer/ (variant: school) to claim copyright over any work
	created by the employee during the term of the contract.  In
	this case, it’s arguably better for all parties involved to have
	the employer’s position clarified and known.  Copyright
	assignment is one, though perhaps not the only, way it can be done.

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Re: Regarding copyright assignment to FSF

[Michael Banck]

Hi,

On Thu, Aug 12, 2021 at 12:18:20PM +1000, Damien Zammit wrote:
> On 11/8/21 11:01 pm, Ludovic Courtès wrote:
> > It would be interesting to consider dropping the copyright assignment
> > requirement for Hurd/Mach/MiG.  For what remains primarily a hobby
> > project, this looks to me like a hindrance more than anything else.
> 
> I imagine it is slightly inconvenient for new contributors, but not a
> hindrance in my opinion.

The fact that this process potentially or apparently took (or rather,
has been taking) months for Sergey (I don't know when it was initiated),
is a pretty good indicator that it is more than a nuisance.

> It ensures that FSF has complete control of the licensing.

I don't mind that, but I also think the Hurd is not a tactical FSF asset
anymore that needs to be kept under tight control. The FSF has enough
copyright in the Hurd that it can enforce it whenever it likes, even if
other people's copyrighted code (as is already the case with the pfinet
stack) is added. Finally, the GPLv2+ code can always be licensed to
GPLv3+ once all the GPLv2only code has been removed, no copyright
assignments are required there, either.

So if the Hurd maintainers would like to drop the requirement (as has
been done with GCC and glibc in recent months), I would support that.


Michael

Re: Regarding copyright assignment to FSF

[Sergey Bugaev]

On Sat, Aug 14, 2021 at 8:43 AM Michael Banck <mbanck@gmx.net> wrote:
> The fact that this process potentially or apparently took (or rather,
> has been taking) months for Sergey (I don't know when it was initiated),
> is a pretty good indicator that it is more than a nuisance.

Well, this is partly my own fault: I've been postponing trying to scan
the signed papers (I can hack on kernel internals alright, but ask me
to deal with a scanner and I'm lost). But that being said, the FSF has
also been consistently slow to respond, so it would take months even
if I had done everything promptly.

Sergey

Re: Regarding copyright assignment to FSF

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 845 bytes --]


Michael Banck <mbanck@gmx.net> writes:

> I don't mind that, but I also think the Hurd is not a tactical FSF asset
> anymore that needs to be kept under tight control. The FSF has enough
> copyright in the Hurd that it can enforce it whenever it likes, even if
> other people's copyrighted code (as is already the case with the pfinet

I wouldn’t be so sure about that.

1. Without copyright assignment of all code involved, enforcement
   becomes much harder.
2. The Hurt still provides capabilities other OS’es don’t — while
   maintaining POSIX compatibility. We’ve seen audacity basically
   being taken over by a company in the past months, so the danger of
   losing Hurd to proprietarization rather got bigger than smaller.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: Regarding copyright assignment to FSF

[Michael Banck]

Hi,

On Sat, Aug 14, 2021 at 02:19:12PM +0200, Dr. Arne Babenhauserheide wrote:
> Michael Banck <mbanck@gmx.net> writes:
> 
> > I don't mind that, but I also think the Hurd is not a tactical FSF asset
> > anymore that needs to be kept under tight control. The FSF has enough
> > copyright in the Hurd that it can enforce it whenever it likes, even if
> > other people's copyrighted code (as is already the case with the pfinet
> 
> I wouldn’t be so sure about that.
> 
> 1. Without copyright assignment of all code involved, enforcement
>    becomes much harder.

I don't think "much harder" can be quantified in a meaningful way,
seeing how parts of the Hurd aren't under the FSF copyright at this
point, anyway.

> 2. The Hurt still provides capabilities other OS’es don’t — while
>    maintaining POSIX compatibility. We’ve seen audacity basically
>    being taken over by a company in the past months, so the danger of
>    losing Hurd to proprietarization rather got bigger than smaller.

Nobody proposes that the FSF relicenses the Hurd to a non-copyleft
license before relinquishing the copyright assignment mandate, so I
don't see how the Hurd continueing to be under a GPLv2+ license will
ever be able to be taken proprietary.

I'm not going to respond further on this thread, this is starting to get
off-topic really quick and if there are further things to be discussed,
gnu-system-discuss or whatever other mailing list is likely the better
place.


Michael

Re: Regarding copyright assignment to FSF

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 3243 bytes --]


Michael Banck <mbanck@gmx.net> writes:

> Hi,
>
> On Sat, Aug 14, 2021 at 02:19:12PM +0200, Dr. Arne Babenhauserheide wrote:
>> Michael Banck <mbanck@gmx.net> writes:
>> 
>> > I don't mind that, but I also think the Hurd is not a tactical FSF asset
>> > anymore that needs to be kept under tight control. The FSF has enough
>> > copyright in the Hurd that it can enforce it whenever it likes, even if
>> > other people's copyrighted code (as is already the case with the pfinet
>> 
>> I wouldn’t be so sure about that.
>> 
>> 1. Without copyright assignment of all code involved, enforcement
>>    becomes much harder.
>
> I don't think "much harder" can be quantified in a meaningful way,
> seeing how parts of the Hurd aren't under the FSF copyright at this
> point, anyway.

A real life example is GNU Guix.  There are (probably) more than hundred
copyright holders (ain't I right, Ludo?).  Is it possible enforce the
copyright of that package?  All copyright holders must cooperate to
enforce GPL, which is probably impossible.

>> 2. The Hurt still provides capabilities other OS’es don’t — while
>>    maintaining POSIX compatibility. We’ve seen audacity basically
>>    being taken over by a company in the past months, so the danger of
>>    losing Hurd to proprietarization rather got bigger than smaller.
>
> Nobody proposes that the FSF relicenses the Hurd to a non-copyleft
> license before relinquishing the copyright assignment mandate, so I
> don't see how the Hurd continueing to be under a GPLv2+ license will
> ever be able to be taken proprietary.

When copyright is not enforced, there is no difference between a GPL
licensed and a public domain software.  When a company sees that the
copyright isn't enforced of a GPLed, it can take the program and make it
proprietary.

> I'm not going to respond further on this thread, this is starting to get
> off-topic really quick and if there are further things to be discussed,
> gnu-system-discuss or whatever other mailing list is likely the better
> place.
>
>
> Michael

NOTE: I am not a lawyer.

-- 
Akib Azmain Turja

This message is signed by me with my GnuPG key.  It's fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

Get it with:

    gpg --recv-keys 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5

See https://emailselfdefense.fsf.org/ to learn more and protect your
emails and yourself from surveillance.  Please send me encrypted
messages whenever possible.

Never send me Microsoft Office attachments, they use secret proprietary
format so I'll fail to read and trash them; send them in plain text if
possible or in formats like ODF and PDF if your document contains images
or videos. See http://www.gnu.org/philosophy/no-word-attachments.html to
learn more.

Please don't send HTML emails, use plain text.  HTML emails are usually
vulnerable, about thousand times larger than plain text and look ugly to
me.  They contain trackers, so whenever someone opens a messsage he is
tracked by third-party.  See http://www.asciiribbon.org to learn more.

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]