It’s a bit of a silly situation, I ran into it before when I created a flake for an unfree application. You can’t allow that unfree application in your nixpkgs system instantiation because the evaluation fails in the application flake; however, allowing that package there allows it on any system that uses the flake, even if they disallow unfree in their nixpkgs.
The input doesn’t really matter, it’s how the input is actually used in the flake. In fact it might be the overriding that is causing the issue in the first place when the flake you’re evaluating uses an older nixpkgs where the offensive package isn’t marked insecure yet and hence isn’t explicitly permitted, and then it fails because you’re overriding it with a nixpkgs where it is marked insecure.
I’m not sure this is the case here, but I once had it that an insecure package was a dependency of a package outside nixpkgs, in that case you need to allow the insecure package where the other package was defined. Your package whitelist only applies to your nixpkgs insurance, a non-nixpkgs package will use its own instance
Well, it doesn’t silently ignore files, it tells you if the work tree is dirty.
Though I’ve tripped over the different behaviors of the repl vs the rest of the tools myself in funny ways
Are you also building your project using nix?
It’s certainly very helpful with that, I can say I learned quite a bit about nix, but also about flake-parts during the migration and I’d say the latter is criminally underrated in the community.
What do you mean? Dendritic approach or having modules in a separate flake? Or both?
nix
Oh, that’s good to know.
I think this is a huge release of just because of accessibility, that’s always been a pain point (read: basically impossible) with LaTeX, I heard ConTeXt is better there but I never got into it. typst on the other hand is very approachable and makes a lot of sense.
While I don’t need accessibility very much nowadays, it’s basically a requirement for usage in the public sector here as PDF/UA. Which I guess is the main motivation.
Looking forward to trying it out when it hits my repositories, which should be soonish.
Another option is docbook, but I never particularly enjoyed working with that…
Similarly here. Have an Odroid with that platform, it wasn’t cheap but it came with several advantages:
Very powerful machine for the power usage, I ran a really old Athlon before though (from 2010 or so that I retrofitted with 16GB RAM) that did most stuff just fine. But I wanted some transcoding and also possibly a smaller case.
I run everything bare metal though.
Luckily, it’s only the entire Internet, just the unfun part.
I don’t see any issues with these subvolumes for NixOS (though I haven’t used NixOS on btrfs, just assuming it works) – Create the partition and its subvolumes manually and then perform the steps at https://wiki.nixos.org/wiki/Btrfs. It shouldn’t be an issue
Client data absolutely is encrypted in TLS. You might be thinking of a few fields sent in the clear, like SNI, but generally, it’s all encrypted.
I never said it isn’t, but it’s done using symmetric crypto, not public key (asymmetric) crypto.
Asymmetric crypto is used to encrypt a symmetric key, which is used for encrypting everything else (for the performance reasons you mentioned).
Not anymore, this was only true for RSA key exchange, which was deprecated in TLS 1.2 (“Clients MUST NOT offer and servers MUST NOT select RSA cipher suites”). All current suites use ephemeral Diffie-Hellman over elliptic curves for key agreement (also called key exchange, but I find the term somewhat misleading).
As long as that key was transferred securely and uses a good mode like CBC, an attacker ain’t messing with what’s in there.
First, CBC isn’t a good mode for multiple reasons, one being performance on the encrypting side, but the other one being the exact reason you’re taking about: it is in fact malleable and as such insecure without authentication (though you can use a CMAC, as long as you use a different key). See https://pdf-insecurity.org/encryption/cbc-malleability.html for one example where this exact property is exploited (“Any document format using CBC for encryption is potentially vulnerable to CBC gadgets if a known plaintext is a given, and no integrity protection is applied to the ciphertext.”)
As I wrote in my comment, I was a bit pedantic, because what was stated was that encryption protects the authenticity, and I explained that, while TLS protects all aspects of data security, it’s encryption doesn’t cover the authenticity.
Anyhow, the point is rather moot because I’m pretty sure they won’t get a certificate for the IP anyways.
Public key crypto, properly implemented, does prevent MITM attacks.
It does, but modern public key crypto doesn’t encrypt any client data (RSA key exchange was the only one to my knowledge). It also only verifies the certificates, and the topic was about payload data (i.e. the site you want to view), which asymmetric crypto doesn’t deal with for performance reasons.
My post was not about “does TLS prevent undetected data manipulation” (it does), but rather if it’s the encryption that is responsible for it (it’s not unless you put AES-GCM into that umbrella term).
Right, and for the challenge, you need to have access to a privileged port (which usually implies ownership), which you won’t get assigned.
Let’s Encrypt are rolling out IP-based certs, you may wanna follow its development. I’m not sure if it could be used for your forwarded VPN port, but it’d be nice anyhow
It shouldn’t be because you’re not actually the owner of the IP address. If any user could get a cert, they could impersonate any other.
I believe encryption helps prevent tampering the data between the server and user too. It should prevent for example, someone MITM the connection and injecting malicious content that tells the user to download malware
No, encryption only protects the confidentiality of data. You need message authentication codes or authenticated encryption to make sure the message hasn’t been transported tampered with. Especially stream ciphers like ChaCha (but also AES in counter mode) are susceptible to malleability attacks, which are super simple yet very dangerous.
Edit: this post is a bit pedantic because any scheme that is relevant for LE certificates covers authenticity protection. But it’s not the encryption part of those schemes that is responsible.
Good luck on the journey! What I meant is that over time, you’ll realize that what you did was probably not the most elegant was to do something, at least that’s my experience with my config. Like, I started with a flake with an explicit config for each machine (basically multiple nixosConfigurations) and then turned it into a lib with functions to turn a set of hosts from json into an attribute set (kind of a simple inventory done). My last efforts that are still ongoing (cough) are splitting my NixOS modules off into a separate flake using flake-parts.
I do understand you meant having the stuff that your need work, I just wanted to hint that the language is very powerful and as such, most configurations have room for improvement, as in learning to do things more efficient or do things that weren’t possible before.
NixOS […] learn everything
I don’t think it’s possible to learn everything for NixOS as a casual user / admin. It’s massive. I was luckily able to sneak a NixOS project into work which gave me some paid time on the topic. But there’s always room to learn more about it. Which is a good thing - by its nature, it’s just more powerful than conventional distributions.
Welp sorry for pushing you in the wrong direction