how on earth does openssh not only have incredibly fucked versioning but is the only package i've ever seen to mention a "privilege separation" chroot path which actively breaks non-root builds. are you fucking kidding me bruh. "privilege separation chroot" defaulting to /var/empty and it immediately errors if it can't create it????? why are your version strings like that bruh?????
131
Replies
·
0
Boosts
ok so they decided to reinvent sudo for sshd root https://github.com/openssh/openssh-portable/blob/master/README.privsep if i cannot disable the sshd build (reading ./configure --help in a crazed demented rage did not see the flag for it) i'm going to commit several murders
how do you spend 8kb of text and provide multiple detailed ASCII art diagrams regarding your privilege separation methodology and oh my god wait does it really require sshd to be root too yes it literally does are you fucking kidding me
this is so fucked
sshd is the main entry-point binary for the server. This binary retains privilege but performs a very limited set of tasks: loading and checking the configuration, listening for incoming connections
and monitoring the status of connections through the pre-authentication phase of their lifecycle to implement the MaxStartups and PerSourcePenalties features.
NONE OF THESE THINGS REQUIRE ROOT WHAT THE FUCK
@hipsterelectron Maybe I'm VASTLY missing the point here, but doesn't listening on port 22 require root, because 22 is a privileged port? Isn't there a tradition of servers being forced to use root on linux for this reason even if they don't need it for other reasons?
@psf yes and another example of linux being the problem here is in requiring root for the very chroot call that is used to perform the "privilege separation", making that linux decision by itself necessary for sshd to run as root
@psf i am but a humble build engineer and i wish only to build git and its deps from source and openssh is giving off incredibly fucked vibes
how is anyone ok with this????? it takes half the document and two fork/execs before it gets to why sshd-auth would need root:
All operations that require privilege, such as looking up user information, private key signatures, checking passwords, etc are performed by RPC to the parent sshd-session process.
- looking up user information????????
- i think you can calculate cryptographic signatures without root????
- the fuck do you mean """"checking passwords"""""
i have been informed that even looking up the list of users requires root and have concluded that the unix user model is well-designed to suit the bell labs HR system from the 1970s and was never a serious general permissions model
https://github.com/openssh/openssh-portable/blob/master/LICENCE
i have never seen a stranger license file in my entire life. they also spell the filename in a way i have never seen before
Some code is licensed under a MIT-style license to the following
copyright holders:Free Software Foundation, Inc.
that's not even legally binding and obviously intended as an insult. they also mixed spaces and tabs in indentation???
@hipsterelectron this whole file looks like some sort of experimental poetry..
https://github.com/openssh/openssh-portable/commit/7294baaf6ab389fd206899d68a1ad400ba2f4508
- (djm) Forgot to cvs add LICENSE file
first of all, what a remarkably specific commit description. second of all, that's not worth a ChangeLog entry. third, it's not named LICENSE?
i didn't peruse the whole contents of the LICENCE file because the file being 300 pages long and under a nonstandard filename without symlinks tells me that this is an incredibly politically motivated project. i wonder if that means they're left-wing!
it takes a certain kind of person to use "portable" while using fucking autoconf and then stuffing the LICENCE file with actively contradictory statements
oh and there is a single very clear and absolutely legally actionable statement at the beginning of the LICENSE
Any derived versions of this
* software must be clearly marked as such, and if the derived work is
* incompatible with the protocol description in the RFC file, it must be
* called by a name other than "ssh" or "Secure Shell".
"Any derived versions of this software must be clearly marked as such" is completely incompatible with publishing it via git, but i think that's intentional and it just serves to sound vaguely legal so the line after it sounds legally actionable
that is fucking bizarre. it's also incredibly strange to assign copyright to a single person in the first place. who the fuck is tatu ylonen
https://fi.wikipedia.org/wiki/Tatu_Yl%C3%B6nen english wikipedia has no page on him but i believe finnish wikipedia says he invented ssh. however his own website https://ylonen.org/ then clarifies he wrote "the original ssh" but not openssh which should be sufficient evidence to void his copyright claim over any of the code at all
@hipsterelectron i would have to check, but i think openssh was either a fork of the last permissibly-licensed version or a reimplementation of the protocol. it was quite a long time ago, though you might find closed and archived debian bugs related to the issue.
if you look at the rfcs for the ssh protocol version one, i'm quite sure you will find tatu ylonen as the document author or at least co-author.
as usually with weak copyleft, the whole thing was a mess.
so the actual ssh guy absolutely does incorporate gnu code (i literally bet it was readline) and then this openssh "portable" fork uses his name to scare people while systematically replacing every single gpl dependency. i wonder if they were motivated by the common good!
I'M SO CONFUSEDDDDDD https://github.com/tatuylonen/tokentree/blob/master/tokentree/ctokentree.pyx
- this would literally be easier to read and fewer lines of code to do in C than in the OG slop python c compiler?????
- the entirety of
_add_{with,no}_extra()is repeated??????
# Increment the count of all nodes (doing this here in between
# seems to improve performance by about 5% - probably due to
# memory latencies)
who is this for. who are you doing this for dude
looked up the OG slop python c compiler to see if it would summarize its theory of operation in the README https://github.com/cython/cython it absolutely does not but it does the exact same fucking thing with the obsequious false deference to the "original author" of a completely separate work
python has one of the nicest build systems and tooling for c extensions i have ever used for any FFI and unlike the python language itself the C ABI has extremely well-defined stability guarantees. furthermore this is one of the many tasks that c is good at and python itself makes inordinately annoying.
his website points to https://www.ssh.com/academy/ssh under the title "original ssh", the one he says he wrote, and then that page says he's on twitter and links to https://x.com/tjssh, which has absolutely zero posts but follows more people than i did when i was on there.
so, this guy clearly doesn't exist, or perhaps he died. let's take a look at his rfc history (????)
i notice he literally has all the standard NSA track publications in database design https://ylonen.org/ but then he describes something called "shadow paging" which seems ridiculously similar to my architecture for i/o scheduling
the last time this happened was when i read about alexia massalin's synthesis kernel who also disappeared suddenly around the year 1995 after developing a more efficient chip fabrication technique
unfortunately for my preconceived notions this 2015 NIST document on ssh security is remarkably well-done https://nvlpubs.nist.gov/nistpubs/ir/2015/nist.ir.7966.pdf this paragraph is a fucking banger
Generally it has been found that the cost of manual labor in a key management project is often as big or
even significantly bigger than the cost of the tools for managing the keys. The choice of tools has a major
impact on the amount of manual labor needed.
also stealing this bit from his phd thesis for my phd thesis and adding 40 years
7.2 The Impact of Technological Development
The cost of main memory has dropped dramatically since the rst half of 1980's, when most performance comparisons between shadow paging and logging were made. It is now reasonable to assume that in most applications the entire page table of even a fairly large database will be available in the cache most of the time. Even for very large databases, those parts of the page table which are used frequently will remain in the cache. This has removed the most serious performance problem with shadow paging.
much of the thesis is really boring and uninteresting to me because i do not have the patience to optimize things without upsetting the balance of power. but i'm super glad i looked at the section on snapshotting and dumping because who doesn't love taking dumps
it also provides this SUPER fucking useful line
A snapshot is a transaction-consistent1 copy of the database [1].
[1] Transaction-consistent means that all transactions are either fully re ected in the copy, or not at all. No effects of uncommitted or aborted transactions will be visible in a transaction-consistent copy.
cc @zwol this is from https://ylonen.org/papers/lis-thesis.pdf and to me it produces a wonderful argument: how on earth can you even define a backup without formalising state consistency with something like a transaction? how many backups describe a state that never actually existed on disk because of modifications during the time between the start and conclusion of the backup?
i'm literally sooooooooooo scatterbrained bc i had never in my life really understood the point of a filesystem snapshot except like to restore files that were accidentally deleted but lmao of course snapshots are exactly what git ostensibly records for changes to a filesystem tree
if your filesystem is not like used by a real human being to organize their cute little files while naming their adorable little directories and is instead the input and/or output of a process (probably just the input actually) yes of course you want snapshots
@dragon which do you think is cuter files or directories. i think symlinks are cute but very mysterious and sometimes they can get lonely
i also still have the correct belief that hard links to directories make perfect sense and everyone in the world is wrong about this because you need inodes with hard non-recyclability guarantees to avoid checksumming the same massive file 300 times in a row anyway and there's no way every c programmer ever hasn't wanted this
not the "hard links to directories" part that's a super specialized use case
this is not a reason in itself but the biggest reason by far that hard-linked directories can't be done is because "historically" (which in OS terms means "unix did it because multics did it and suddenly 50 years have passed") the directory structure incorporates basically no form of indirection or abstraction and path resolution largely corresponds to pointer chasing around the hard disk