wodny

And it's also worth noting that eg. Debian has been providing hybrid images for years. Hybrid meaning you can write them directly to block device like USB drive or burn on CD. They exploit the fact that ISO images have first blocks empty and unused so you can put a classic MBR boot loader there.

Why "yikes"? Note that doesn't mean I don't know how to use eg. gdb outside or inside IDE. My debugging record proves my methods are quite efficient but there's something even more important - there are ways to systematically avoid the need to use a debugger by keeping projects' sanity level high.

That is not the point I was trying to make here. I was talking about extreme cases of faulty code which luckily are not that common. I meant that as long as you couple with sane libraries and adhere to standards in your own team extreme measures such as a debugger are not necessary.

> The big thing here is that you seem to only work with your own code, where you can arbitrary refactor it and keep the entire thing in your head, as well as quickly find which module does what.

Not at all. Due to lack of documentation I look at code of foreign libraries and applications all the time to check what really happens inside and what are the guaranties. The latter being often the case when it comes to concurrency problems.

Print debugging is not that different from setting logging level to DEBUG and those logging calls should already be there in code and give meaningful insight so I don't get printing being often ridiculed.

For over ten years of commercial work I used a debugger only a couple of times and in most cases it was against someone else's code, usually when things were completely broken and I needed to get backtraces from multiple deadlocked threads or lacked debugging symbols and things like radare were also required. There were also times when I manually called a syscall using gdb.

My opinion is that if you can't reason about the code helping yourself with just a couple of additional messages the code is probably broken/too complicated to begin with and requires serious refactoring. I've never understood people stepping through a program hoping to find some mysterious creature somewhere along a huge stack of calls. In my career I have often seen people always debugging an application as a whole instead of separated modules. Dividing a problem is the key. The same key that allows me to still program using vim without autocompletion, keep APIs sane and coherent, and avoid dead code.

One really useful exception is when dealing with electronics. My friends programming hardware use debuggers all the time and in this case it actually makes perfect sense because there is no way to print anything and things like hardware interrupts come into play.

I think this is an oversimplification. Just look at the number and the history of PEPs:

- The Theory of Type Hints - PEP 483

- Annotations - PEP 3107 - 3.0

- Type hints - PEP 484 - 3.5

- Variable annotations - PEP 526 - 3.6

- Postponed evaluation - PEP 563 - 3.7 (3.10)

- Core support - PEP 560 - 3.7

- Distribution - PEP 561 - 3.7

- Data Classes - PEP 557 - 3.7

- Literal types - PEP 586 - 3.8

- TypedDict (limit keys) - PEP 589 - 3.8

- Final qualifier - PEP 591 - 3.8

- Static duck typing - PEP 544 - 3.8

- Flexible annotations - PEP 593 - 3.9

- Type Hinting Generics In Standard Collections - PEP 585 - 3.9

It requires a tektonik finish on top.

https://www.youtube.com/watch?v=JqYhuwu614Y

Yelle - A Cause Des Garcons

On the contrary, I've worked with 8 and {32,64}bit x {LE,BE} chips many times and wrote quite a lot of network code in C. But you're mixing syntax with semantics.

An abstraction where "positive" and "negative" mean the same just for safety so they can't be confused with each other.

It isn't a great name, but: it doesn't bare a contradiction in itself (contrary to "serverless"), there was already a tradition of drawing unspecified networks or internet as a cloud in diagrams. So "running in the cloud" as running "somewhere in the network we used to draw as a cloud" has an explanation. Also note, I didn't state that there are only two types of names. I commented on what "bug" and "serverless" is.

The Ministry of Serverless (Miniless) is working on it.

There is a huge difference between a metaphor (resemblance) and contradiction (stating it is and isn't something at the same time).

Nice. I've missed the static binaries on the homepage and should have tried static compilation myself. Now my little python2 and find-based scripts exporting ncdu-compatible outputs[1] on systems without ncdu seem a bit redundant. On the other hand, there are some examples of filtering the output with jq.

[1]: https://github.com/wodny/ncdu-export

Indeed, it was awfully buggy a couple of months ago when I gave it a try. Hope to reiterate in a couple of months. It would be a very useful tool.

No. "Z raku" would mean that "raku" accompanies you and the play on words would be gone because it would be either "programuje z raku" ("one is accompanied by raku the programming language") or "programuje z rakiem" ("codes having/with cancer").

It will have quite interesting implications, especially for former Perl 5 syntax enthusiasts. One could say in Polish they "code in cancer" ("programuje w raku").

Thank you very much for the SOCK_DESTROY. I have completely missed its addition to the kernel.

Or even worse - someone could steal my identity and start answering to JavaScript questions just to frame me.

Drew Neil also created great video tutorials, the vimcasts[1].

[1]: http://vimcasts.org/episodes/

asciio is great, I use it a lot to document architecture of systems.

> The guide is not intended to teach everything about security -- that would be too much.

On the other hand, the objectives list contains: "this guide will attempt to cover as many of them as possible". Despite that, it still misses basic security rules.

"A desktop class computer [...] That I want to be able to SSH to remotely from unknown computers and unknown locations (i.e. a friend's house)."

SSH from an unknown computer? Also see my original comment about what is missing in description of a situation when connecting to your server from a new system.

> Are you saying a public key can be used to decrypt data it encrypted? Or are you saying a public key could also be used to decrypt data that the private key encrypted?

See my discussion with derefr in this thread.

> You mention "server room". This guide is intended for a person running a simple server in their home.

The "server room" here means you are sitting next to your server and can connect point-to-point. It doesn't mean you need a backup diesel generator.

And if it is really about a home server, concerns like "make sure nobody is listening" don't make sense.

> I made some other updates to the guides that I hope address your other concerns?

I've seen you accepted pull requests of some contributors that fixed the basics for you. Because they were generated right after discussion in this thread they concern things discussed here.

> Also, I want more folks to use Linux. Most distributions are so similar there is no value in having so many distribution specific guides -- all it does is create unnecessary confusion and steer potential prospective users away from Linux.

How many (which) distros have you managed as a professional sysadmin to state that with high confidence?

I'm quite sure that a beginner will just choose Ubuntu and proceed to something like https://linuxjourney.com/. If someone becomes more than a hobbyist one will hopefully go and read something from a trusted source, written by sysadmins with a good grasp of contemporary cryptography involved.

It has been mentioned in one of the pull request that this guide was being discussed on HN right after it got here: https://github.com/imthenachoman/How-To-Secure-A-Linux-Serve....

There are two fresh threads on Reddit:

https://www.reddit.com/r/linuxadmin/comments/arx7xo/howtosec...

https://www.reddit.com/r/linux/comments/arx7st/howtosecureal...

On the other hand, SSH gives you just that if you verify the fingerprint which is not mentioned in the guide. MITM-proof channel is needed if one gains any kind of shell access because then public key substitution can happen in various ways, even without the user him/herself explicitly editing the file. Furthermore, if one allows MITM when accessing shell, substituting the public key is just one of very serious security problems.

The fact you have the private key permits access, not possession of the public key even though the public key is the one you add to the file on the server side (asymmetric cryptography). The "secure way" may also suggest that you have to keep your public key secret which is not true.

I see no point, there are enough guides already and I don't consider myself competent enough in that field to teach others. I think it shouldn't be about fixing every particular mistake in the guide. It's about changing attitude to "I won't write something unless I have a lot of experience". Otherwise it becomes a cat and mouse chase and managing basics for the author.

Nice. I admit, I haven't read the whole thing.

"No, one shouldn’t" suggests that you don't use public key when encrypting data. "Verifying a signature […] is […] “decrypting with the public key” is the part I meant when writing that the original statement is "cryptographically inaccurate" - it's algorithmically feasible. But also mind that this specific kind of encryption has a specific name - "signing". You can't state that: "no, one shouldn't use public key for encrypting data".

This guide contains (at least) inaccurate statements. It's oversimplifying and omitting important things while putting emphasis on some exotic details where defaults would be sane enough.

"One key, the public key, can only encrypt data, not decrypt it" - this is cryptographically inaccurate. One should use it that way, though.

"Identity is verified by encrypting and decrypting data that both the client and server know". That's not how signing works. The crucial part of the process is to first establish an encrypted channel, then choose something random (not used previously) and finally verify the signature is correct. What exactly would be the data that "both the client and server know"?

"If you're sure there is nobody listening between the client you're on and your server, you can use ssh-copy-id to transfer and append the public key". Almost never happens unless you're in the server room, connected point-to-point. But then the remark about someone listening doesn't make sense. And not a single word about verifying server's fingerprint in the whole guide.

"Keep in mind doing this means you can't use the key for automation because you'll have no way to send the passphrase in your scripts". Unless you use an ssh-agent.

"umask is a Bash built-in which means a user can change their own umask setting". Wrong implication here. umask is a syscall. It doesn't matter what you use to call it. And what if you're using a different shell?

Suggesting painful default umask instead of just doing `chmod go-rwx $HOME` and adjusting /etc/adduser.conf is debatable.

Making this guide "distribution agnostic" is IMHO futile and there already are some distribution-specific guides like https://debian-handbook.info/.

So I will answer myself. Experiments suggest it is like that: https://www.reddit.com/r/linux/comments/apmptq/cve20195736_r...

The vulnerability description seems to be lacking an explanation why the /proc/$PID/exe symlink is so special and why using the #!/proc/self/exe hashbang will work while using #!/usr/sbin/runc probably won't. Am I right that the proc filesystem in proc_exe_link() fills the file_operations struct in a way that causes open() not to go through a dereferencing procedure using the filesystem but just open the file used to run the executable?