| View previous topic :: View next topic |
| Author |
Message |
nokilli
Apprentice
Joined: 25 Feb 2004
Posts: 228
|
 Posted: Thu Jan 16, 2025 3:08 am Post subject: |
 |
|
| pingtoo wrote: | If unaware of there is man in the middle and use kernel as nbd client than any security done at operating system are lost.
the middle have opportunity to control anything kernel can do (read/write file content, execute new process without visibility). |
| pingtoo wrote: | | Are you aware when running nbd-client the program just initiate kernel to contact remote nbd server? the nbd-client program does not perform any I/O for the connected NBD device. |
You answered your own question. The kernel is managing this connection just as it does all of the others.
Whatever the risk is being borne by the kernel acting as client, it appears to be identical to the risk borne hosting any other connection.
The kernel is our client. The protocol is simpler than ping. I honestly don't see the problem, but sure, Linux is huge.
_________________
We are the block device. The kernel is our client. |
|
| Back to top |
|
 |
nokilli
Apprentice
Joined: 25 Feb 2004
Posts: 228
|
| Posted: Thu Jan 16, 2025 3:11 am Post subject: |
|
|
| pjp wrote: | | nokilli wrote: | | There is an implicit final tuple of (Math.MAXINT, 1), |
Presuming search results are correct, that's a go-ism. |
They aren't correct, I mistyped.
Should have said, (2**64, 1).
I know a few languages but as I get older as I switch from one to another, more and more the previous language sort of stays stuck in the matrix.
_________________
We are the block device. The kernel is our client. |
|
| Back to top |
|
|
nokilli
Apprentice
Joined: 25 Feb 2004
Posts: 228
|
| Posted: Thu Jan 16, 2025 3:40 am Post subject: |
|
|
| pjp wrote: | | Of the threats to be concerned with, I just don't see Linux package managers as being a concern. If you were somehow obligated to use RedHat or Canonical, or some obscure distro, I'd understand more. |
Again, it was Fedora rpm-ostree's seeming insistence on denying users proxied access to their repository that got me rolling on this.
And what did I do? I come racing back to Gentoo.
That doesn't mean we can't benefit from a trustless package manager.
Who would you trust more? The package manager that insists on making you connect directly to their servers with an encrypted connection? Or the package manager that lets you manage your installation in an entirely trustless fashion, so much so you don't even need to think about it? Who's got your back?
You guys are taking this personally. Stop it. Read the news. Who do you trust today to keep your system secure when the whole space is a house of mirrors?
Seriously, come up with a good name. Gentoo Hardened was great! Something like that, that conveys a focus on making everything it can trustless, exploiting the one feature that no other distro has: we're source-based.
Why is that important? Because if we do the NBD server right, we can make it really fast for users we can assess to be using the service responsibly. There are places where time to getting a patched system up and running is important, yes?
NBD is fully asynchronous, did you know that? It means our client, the Linux kernel, can request blocks in one order and we, the block device, can serve them in some other order. This means we can easily support burst transfer rates for responsible users even within a strict rate limiting regime that keeps bandwidth abusers in the bulk queue.
_________________
We are the block device. The kernel is our client. |
|
| Back to top |
|
|
nokilli
Apprentice
Joined: 25 Feb 2004
Posts: 228
|
| Posted: Thu Jan 16, 2025 3:58 am Post subject: |
|
|
Facing the serious prospect that the tarballs won't be stable.
Again, if the plan is to store the package source in addition to the tarballs so that the user only need download the one file as opposed to many, there is still the problem of verifying package integrity since it's the tarball that gets signed by upstream, right?
And while you can expand the package source from a tarball, and then recreate the tarball from that source, and do indeed end up with a tarball that contains the same files, it's maybe not the same bits. Upstream is signing a hash of the tarball. One bit out of place and it all breaks.
Add to the complexity, I bet the underlying file system plays an important role. Projects die on these rocks all the time.
For the moment I'm going to assume there's an answer, perhaps some additional process in addition to expanding all of these tarballs that produces some kind of hint file that can be used better construct the tarball on the user's end? If this really can save significant bandwidth then addressing that complexity would be worth it, no?
(cpio guys are doing picard_facepalm.jpg)
_________________
We are the block device. The kernel is our client. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
