starred/netboot.xyz

Fork 0

mirror of https://github.com/netbootxyz/netboot.xyz.git synced 2026-04-25 15:15:56 +03:00

[GH-ISSUE #31] Checksum images #1557

New issue

Closed

opened 2026-03-01 18:34:23 +03:00 by kerem · 8 comments

kerem commented

2026-03-01 18:34:23 +03:00

Owner

Originally created by @avindra on GitHub (Jan 14, 2016).
Original GitHub issue: https://github.com/netbootxyz/netboot.xyz/issues/31

Would it be possible to do a checksum (preferably SHA256) of all the images after they are downloaded?

Originally created by @avindra on GitHub (Jan 14, 2016). Original GitHub issue: https://github.com/netbootxyz/netboot.xyz/issues/31 Would it be possible to do a checksum (preferably SHA256) of all the images after they are downloaded?

kerem

2026-03-01 18:34:23 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-03-01 18:34:24 +03:00

Author

Owner

@antonym commented on GitHub (Jan 14, 2016):

There's a provision in iPXE for signing images and then verifying their signatures:

http://ipxe.org/cmd/imgverify
http://ipxe.org/crypto

At some point I'll look into the feasibility of doing so, at the very least on some of the lesser known mirrors/images.

@antonym commented on GitHub (Jan 14, 2016): There's a provision in iPXE for signing images and then verifying their signatures: http://ipxe.org/cmd/imgverify http://ipxe.org/crypto At some point I'll look into the feasibility of doing so, at the very least on some of the lesser known mirrors/images.

kerem commented

2026-03-01 18:34:24 +03:00

Author

Owner

@dbohdan commented on GitHub (Jan 18, 2016):

@antonym This would be excellent.

If you do implement signature checking consider doing it for all images and mirrors. The most-downloaded images may be hosted on servers that are better maintained but they also represent the most desirable target for attackers.

@dbohdan commented on GitHub (Jan 18, 2016): @antonym This would be excellent. If you do implement signature checking consider doing it for all images and mirrors. The most-downloaded images may be hosted on servers that are better maintained but they also represent the most desirable target for attackers.

kerem commented

2026-03-01 18:34:24 +03:00

Author

Owner

@avindra commented on GitHub (Jan 20, 2016):

The most-downloaded images ... represent the most desirable target for attackers.

Agree. We should be cognizant of this when making modern infrastructure tooling.

@avindra commented on GitHub (Jan 20, 2016): > The most-downloaded images ... represent the most desirable target for attackers. Agree. We should be cognizant of this when making modern infrastructure tooling.

kerem commented

2026-03-01 18:34:24 +03:00

Author

Owner

@antonym commented on GitHub (Feb 4, 2016):

The groundwork is now laid out for checking all images being downloaded. I'm currently generating signatures of the netboot.xyz sources during deployment and then verifying as each menu item is loaded. The next step will be to verify the signatures of the remotely downloaded images which I'll probably have time for in the next week or two.

@antonym commented on GitHub (Feb 4, 2016): The groundwork is now laid out for checking all images being downloaded. I'm currently generating signatures of the netboot.xyz sources during deployment and then verifying as each menu item is loaded. The next step will be to verify the signatures of the remotely downloaded images which I'll probably have time for in the next week or two.

kerem commented

2026-03-01 18:34:24 +03:00

Author

Owner

@mirabilos commented on GitHub (Apr 25, 2016):

Is there any way to delegate sigining for particular images to the project responsible for them? The imgverify command has a --signer option; this would allow you to use your own main signature key for netboot.xyz itself and those images signed by you, and allow me to re-sign the MirBSD images every time I upload an updated snapshot (it’s a -current image, i.e. updated occasionally, as we’re not doing formal releases at the moment).

@mirabilos commented on GitHub (Apr 25, 2016): Is there any way to delegate sigining for particular images to the project responsible for them? The `imgverify` command has a `--signer` option; this would allow you to use your own main signature key for netboot.xyz itself and those images signed by you, and allow me to re-sign the MirBSD images every time I upload an updated snapshot (it’s a -current image, i.e. updated occasionally, as we’re not doing formal releases at the moment).

kerem commented

2026-03-01 18:34:24 +03:00

Author

Owner

@antonym commented on GitHub (Apr 26, 2016):

Right now I'm retrieving the binaries remotely at a point in time and signing them. It's super rough and I haven't had a ton of time to work on it recently. I still need to have it only resign when needed instead of every time I run the job. The rolling releases make it more difficult because then they can potentially break and there's not really a good way to alert me about that yet other than setting up a periodic check.

My signature retrieval scripts and generators are here:

https://github.com/antonym/netboot.xyz-sigs/blob/master/generate-bsd-sigs.sh

@antonym commented on GitHub (Apr 26, 2016): Right now I'm retrieving the binaries remotely at a point in time and signing them. It's super rough and I haven't had a ton of time to work on it recently. I still need to have it only resign when needed instead of every time I run the job. The rolling releases make it more difficult because then they can potentially break and there's not really a good way to alert me about that yet other than setting up a periodic check. My signature retrieval scripts and generators are here: https://github.com/antonym/netboot.xyz-sigs/blob/master/generate-bsd-sigs.sh

kerem commented

2026-03-01 18:34:24 +03:00

Author

Owner

@mirabilos commented on GitHub (Apr 26, 2016):

Antony Messerli dixit:

Right now I'm retrieving the binaries remotely at a point in time and
signing them.

Hmm. In this case, please do not do that for MirBSD, as it’ll
break when we publish newly generated images, which are done
“occasionally”.

It's super rough and I haven't had a ton of time to work on it
recently. I still need to have it only resign when needed instead of
every time I run the job. The rolling releases make it more difficult

Sure, I understand it’s all on spare time, same here ☺

bye,
//mirabilos

@mirabilos commented on GitHub (Apr 26, 2016): Antony Messerli dixit: > Right now I'm retrieving the binaries remotely at a point in time and > signing them. Hmm. In this case, please do _not_ do that for MirBSD, as it’ll break when we publish newly generated images, which are done “occasionally”. > It's super rough and I haven't had a ton of time to work on it > recently. I still need to have it only resign when needed instead of > every time I run the job. The rolling releases make it more difficult Sure, I understand it’s all on spare time, same here ☺ bye, //mirabilos

kerem commented

2026-03-01 18:34:25 +03:00

Author

Owner

@antonym commented on GitHub (Nov 13, 2018):

Cleaning up, this was implemented a while ago for quite a few of the OS distros and additional checks will be added as needed.

@antonym commented on GitHub (Nov 13, 2018): Cleaning up, this was implemented a while ago for quite a few of the OS distros and additional checks will be added as needed.

kerem referenced this issue

2026-03-01 18:42:21 +03:00

[PR #1557] [MERGED] Release 2.0.84 #3004

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/netboot.xyz#1557

No description provided.

Rows
Columns