Fwd: Hurd Security vulnerabilities, please upgrade!

[jbranso]

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

 Forwarded message ---
From: "Samuel Thibault" 
To: debian-h...@lists.debian.org, hurd-...@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
-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: Project direction with testing changes (branches and patches)

[Christopher Baines]

Ludovic Courtès  writes:

> Christopher Baines  skribis:
>
>> So, I think I've recently switched to thinking about the problem as one
>> of testing changes, rather than just testing patches. Since both patch
>> series, and branches are used to propose changes, I think this makes
>> sense.
>>
>> In abstract, when testing a change, I would break down the problem as
>> follows:
>>
>>   - You need to work out what's affected by the change, so that you can
>> assess the impact
>>
>>   - Once you know what's effected, you can then build those
>> packages/system tests/... and compare the build statuses and outputs
>> against some baseline
>>
>>   - Then there's the general UI component, ideally a first time
>> contributor would be able to take advantage of automatic feedback
>> about a patch they submit. There's multiple other groups of users
>> though, like patch reviewers, and committers for example.
>
> Makes sense to me.
>
> I agree that the first problem, seeing what’s affected by a change, is
> solved, but it’s still hard to get that info.  I think we could have a
> special “skin” for the Guix Data Service to make it easier for people to
> view specifically this information.  IMO the current UI has the upside
> that it’s generic and exposes all the available information, but it has
> the downside that it’s generic and exposes all the available
> information.  :-)
>
> Or we could extend Julien’s Gitile¹ to include links from commits to
> lists of changed packages.
>
> The UI doesn’t have to be a web UI actually; we could use the Data
> Service client interface at
> 
> and write a new CLI, Emacs mode (similar to ‘M-x build-farm’), or
> something.
>
> ¹ https://git.lepiller.eu/gitile

Indeed, the technical side of detecting changes is solved, but I agree
that there's work needed on making that information useful.

>> I think the first two sub-problems are effectively solved. The Guix Data
>> Service is able to determine the changes between two revisions (assuming
>> it's processed them). The Guix Build Coordinator can then be used to
>> build the relevant packages/system tests, and report that information
>> back to the Guix Data Service.
>>
>> The UI part is much less certain, I've done some work with Patchwork,
>> and I do have some ideas in mind, but there's still more thinking and
>> work to do in this area.
>>
>> Before pressing on though, I think it would be good to know if this is a
>> viable direction?
>
> I think we desperately need more automation, even more than when you
> started working on this!
>
> I think a first step could be to make info from the Guix Data Service
> more readily available, as suggested above.  And from there we could
> address #2 and #3.
>
> The Patchwork instance you maintain at
> 
> does a large part of what we want, though the UI is not my favorite I
> must say.  ;-)  I wonder if we could again make minimal changes to Mumi
> so that it includes links to the relevant bits at the Data Service.
> That’d make it more readily available.  WDYT?

I think using Patchwork or Mumi is viable, it would probably not be
great to use both in the long term. The most useful thing for me would
be to pick an approach.

Patchwork is closer in terms of features I think, since it has an API
for patch series and checks. I know mumi gained the ability to generate
mbox files for patch series now though.

I think the requirements in terms of Mumi would be to have some way of
querying for patch series to test, or at least all/recent patch
series. I suppose something could just ask for the 1st or latest series
each time there's an email to a issue, that might be the simplest
approach. Then there's the bits you describe about showing relevant
information about whatever tests take place. I guess Mumi would need an
API or some way to find out about that information, and then display
it. Maybe that could happen in the form of emails with machine+human
readable data that Mumi could interpret.

Unfortunately I don't know much about the Mumi internals. Ricardo, are
you able to comment on the feasibility and whether this direction would
make sense?

>> Currently, there's no automated testing of patches, and testing of
>> branches is limited to the information that Cuirass provides on failed
>> builds. What I'm proposing for the future is: using the Guix Data
>> Service together with the Guix Build Coordinator to analyse the effects
>> of changes, whether that be from a patch series or a branch. I realise
>> that I've already been experimenting with this, what I'm mostly
>> referring to here is moving towards this being the documented approach,
>> maintained by the project, not just me.
>
> From an administrative standpoint, I very much agree that this sort of
> infrastructure should be financially supported by the project rather
> than by an 

Re: #f as a package description, gnu: Add rocminfo.

[Christopher Baines]

Lars-Dominik Braun  writes:

> Hi Christopher,
>
>> Anyway, I wouldn't like for this change to lower the standard though,
>> it's currently the only package in Guix with an invalid description (as
>> far as I'm aware), is there some reason why it doesn't have one?
> it simply fell through the cracks[1]. Commit
> 0a379de3249d5e9ff66fb404f7e5aa8ce2cb3d24 adds a proper descripton.
>
> Sorry for the trouble,

No problem, thanks for fixing it.

> [1] Unfortunately I cannot run `guix lint` on an entire git changeset,
> so instead I have to check each package by hand and I probably missed
> rocminfo. I wish someday we can have a branch/pull-request-based
> workflow with automated CI checks (linting, `guix pull`, signature
> verification, …) *before* merging to master.

This is something I've put some time in to, but it needs some general
support before I'm confident that the things I have in mind can become
reality. I recently started a thread on guix-devel [1] about what I have
in mind, so please comment if you're interested in this area.

1: https://lists.gnu.org/archive/html/guix-devel/2021-08/msg1.html


signature.asc
Description: PGP signature

Substitute timeouts

[Mathieu Othacehe]

Hello,

I have been investigating a problem that is visible both on the main
guix publish server at https://ci.guix.gnu.org[1] and on the Cuirass
build farm[2].

This error comes from the fact that the publish server does not accept
the "guix substitute" connection requests within the %fetch-timeout
duration of 5 seconds.

The main guix publish server is using a cache. If a requested narinfo is
not in the cache, it will be baked and the client receives a 404
error. Since ecaa102a58ad3ab0b42e04a3d10d7c761c05ec98 and the
introduction of the bypass mechanism, small store items are directly
returned.

This means that the "narinfo-string" procedure can be called directly in
the main publish thread. Running perf on the main publish server reveals
that this procedure can be really expensive under IO pressure (GC
running for example) because it opens a lot of files. I have observed
that the "read-derivation-from-file" call can take up to 600 ms.

If multiple clients were to ask narinfo of several items not yet cached,
under IO pressure, I think that the publish server could become
unresponsive and cause the timeout errors.

The fact that Cuirass triggers the baking of successfully built
derivations probably doesn't help here.

Now regarding the timeout errors that are much more frequent on the
Cuirass build farm, the cause varies a bit. The Cuirass publish server
running on Berlin does not use a cache. This means that the
"narinfo-string" procedure is called for each request, in the main
thread.

To fix those issues, a solution could be to run the "narinfo-string" in
a separate thread, but it will make the publish server code even harder
to understand. My proposition would be to get rid of the bypass
mechanism and instead implement a retry when some substitutes are
reported as being baked, as proposed by Miguel[3].

I think this is the most reasonable solution. This way, users won't
receive 404 errors and start building substitutes that are being
baked[4].

It will also allow the Cuirass build farm to use directly the main guix
publish server, simplifying the current CI setup.

There's a proposed patch attached, WDYT?

Thanks,

Mathieu

[1]: https://issues.guix.gnu.org/49089
[2]: https://issues.guix.gnu.org/48468
[3]: https://issues.guix.gnu.org/44193#2
[4]: http://issues.guix.gnu.org/33370



patch
Description: Binary data

Re: #f as a package description, gnu: Add rocminfo.

[Lars-Dominik Braun]

Hi Christopher,

> Anyway, I wouldn't like for this change to lower the standard though,
> it's currently the only package in Guix with an invalid description (as
> far as I'm aware), is there some reason why it doesn't have one?
it simply fell through the cracks[1]. Commit
0a379de3249d5e9ff66fb404f7e5aa8ce2cb3d24 adds a proper descripton.

Sorry for the trouble,
Lars

[1] Unfortunately I cannot run `guix lint` on an entire git changeset,
so instead I have to check each package by hand and I probably missed
rocminfo. I wish someday we can have a branch/pull-request-based
workflow with automated CI checks (linting, `guix pull`, signature
verification, …) *before* merging to master.