• 0 Posts
  • 56 Comments
Joined 1 year ago
cake
Cake day: July 14th, 2023

help-circle
  • Is it possible to force a corruption if a disk clone is attempted?

    Anything that corrupts a single file would work. You could certainly change your own disk cloning binaries to include such functionality, but if someone were accessing your data directly via their own OS, that wouldn’t be effective. I don’t know of a way to circumvent that last part other than ensuring that the data isn’t left on disk when you’re done. For example, you could use a ramdisk instead of non-volatile storage. You could delete or intentionally corrupt the volume when you unmount it. You could split the file, storing half on your USB flash drive and keeping the other half on your PC. You could XOR the file with contents of another file (e.g., one on your USB flash drive instead of on your PC) and then XOR it again when you need to access it.

    What sort of attack are you trying to protect from here?

    If the goal is plausible deniability, then it’s worth noting that VeraCrypt volumes aren’t identifiable as distinct from random data. So if you have a valid reason for having a big block of random data on disk, you could say that’s what the file was. Random files are useful because they are not compressible. For example, you could be using those files to test: network/storage media performance or compression/hash/backup&restore/encrypt&decrypt functions. You could be using them to have a repeatable set of random values to use in a program (like using a seed, but without necessarily being limited to using a PRNG to generate the sequence).

    If that’s not sufficient, you should look into hidden volumes. The idea is that you take a regular encrypted volume, whose free space, on disk, looks just like random data, you store your hidden volume within the free space. The hidden volume gets its own password. Then, you can mount the volume using the first password and get visibility into a “decoy” set of files or use the second password to view your “hidden” files. Note that when mounting it to view the decoy files, any write operations will have a chance of corrupting the hidden files. However, you can supply both passwords to mount it in a protected mode, allowing you to change the decoy files and avoid corrupting the hidden ones.


  • It sounds like you want these files to be encrypted.

    Someone already suggested encrypting them with GPG, but maybe you want the files themselves to also be isolated, even while their data is encrypted. In that case, consider an encrypted volume. I assume you’re familiar with LUKS - you can encrypt a partition with a different password and disable auto-mount pretty easily. But if you’d rather use a file-based volume, then check out VeraCrypt - it’s a FOSS-ish [1], cross-platform tool that provides this capability. The official documentation is very Windows-focused - the ArchLinux wiki article is a pretty useful Linux focused alternative.

    Normal operation is that you use a file to store the volume, which can be “dynamic” with a max size or can be statically sized (you can also directly encrypt a disk partition, but you could do that with LUKS, too). Then, before you can access the files - read or write - you have to enter the password, supply the encryption key, etc., in order to unlock it.

    Someone without the password but with permission to modify the file will be capable of corrupting it (which would prevent you from accessing every protected file), but unless they somehow got access to the password they wouldn’t be able to view or modify the protected files.

    The big advantage over LUKS is ease of creating/mounting file-based volumes and portability. If you’re concerned about another user deleting your encrypted volume, then you can easily back it up without decrypting it. You can easily load and access it on other systems, too - there are official, stable apps on Windows and Mac, though you’ll need admin access to run them. On Android and iOS options are a bit more slim - EDS on Android and Disk Decipher on iOS. If you’re copying a volume to a Linux system without VeraCrypt installed, you’ll likely still be able to mount it, as dm-crypt has support for VeraCrypt volumes.

    • 1 - It’s based on TrueCrypt, which has some less free restrictions, e.g., c. Phrase "Based on TrueCrypt, freely available at http://www.truecrypt.org/" must be displayed by Your Product (if technically feasible) and contained in its documentation.”

  • That’s still a single point of failure.

    So is TLS or the compromise of a major root certificate authority, and those have no bearing on whether an approach qualifies as using 2FA.

    The question is “How vulnerable is your authentication approach to attack?” If an approach is especially vulnerable, like using SMS or push notifications (where you tap to confirm vs receiving a code that you enter in the app) for 2FA, then it should be discouraged. So the question becomes “Is storing your TOTP secrets in your password manager an especially vulnerable approach to authentication?” I don’t believe it is, and further, I don’t believe it’s any more vulnerable than using a separate app on your mobile device (which is the generally recommended alternative).

    What happens if someone finds an exploit that bypasses the login process entirely?

    Then they get a copy of your encrypted vault. If your vault password is weak, they’ll be able to crack it and get access to everything. This is a great argument for making sure you have a good vault password, but there are a lot of great arguments for that.

    Or do you mean that they get access to your logged in vault by compromising your device? That’s the most likely worst case scenario, and in such a scenario:

    • all of your logged in accounts can be compromised by stealing your sessions
    • even if you use a different app for your 2FA, those TOTP secrets and passkeys can be stolen - they have to be on a different device
    • you’re also likely to be subject to a ransomware attack

    In other words, your only accounts that are not vulnerable in this situation solely because their TOTP secret is on a different device are the ones you don’t use on that device in the first place. This is mostly relevant if your computer is compromised - if your phone is compromised, then it doesn’t matter that you use a separate password manager and authenticator app.

    If you use an account on your computer, since it can be compromised without having the credentials on device, you might as well have the credentials on device. If you’re concerned about the device being compromised and want to protect an account that you don’t use on that device, then you can store the credentials in a different vault that isn’t stored on your device.

    Even more common, though? MITM phishing attacks. If your password manager verifies the url, fills the password, and fills your TOTP, then that can help against those. Start using a different device and those protections fall away. If your vault has been compromised and your passwords are known to an attacker, but they don’t have your TOTP secrets, you’re at higher risk of erroneously entering them into a phishing site.

    Either approach (same app vs different app) has trade-offs and both approaches are vulnerable to different sorts of attacks. It doesn’t make sense to say that one counts as 2FA but the other doesn’t. They’re differently resilient - that’s it. Consider your individual threat model and one may be a better option than the other.

    That said, if you’re concerned about the resiliency of your 2FA approach, then look into using dedicated security keys. U2F / WebAuthn both give better phishing resistance than a browser extension filling a password or TOTP can, and having the private key inaccessible can help mitigate device compromise concerns.



  • I haven’t worked with Scribus but I’ve heard good things about it, so I don’t think you’d be making a wrong choice by going with it. For this use case, the main reasons I can think of for why LaTeX would be preferable would be:

    • if you preferred working with it, or with a particular LaTeX tool
    • if you want to learn one tool or the other
    • if being able to write a script to create the output is something you want to do and the equivalent is not possible in Scribus


  • If you use that docker compose file, I recommend you comment out the build section and uncomment the image section in the lemmy service.

    I also recommend you use a reverse proxy and Docker networks rather than exposing the postgres instance on port 5433, but if you aren’t familiar with Docker networks you can leave it as is for now. If you’re running locally and don’t open that port in your router’s firewall, it’s a non-issue unless there’s an attacker on your LAN, but given that you’re not gaining anything from exposing it (unless you need to connect to the DB directly regularly - as a one off you could temporarily add the port mapping), it doesn’t make sense to increase your attack surface for no benefit.


  • I’m not the person you responded to, but I can say that it’s a perfectly fine take. My personal experience and the commonly voiced opinions about both browsers supports this take.

    Unless you’re using 5 tabs max at a time, my personal experience is that Firefox is more than an order of magnitude more memory efficient than Chrome when dealing with long-lived sessions with the same number of tabs (dozens up to thousands).

    I keep hundreds of tabs open in Firefox on my personal machine (with 16 GB of RAM) and it’s almost never consuming the most memory on my system.

    Policy prohibits me running Firefox on my work computer, so I have to use Chrome. Even with much more memory (both on 32 GB and 64 GB machines) and far fewer tabs (20-30 at most vs 200-300), Chrome often ends up taking up far too much memory + having a substantial performance drop, and I have to to through and prune the tabs I don’t need right now, bookmark things that can be done later, etc…

    Also, see https://www.techspot.com/news/102871-zero-regrets-firefox-power-user-kept-7500-tabs.html - I’ve never seen anything similar for Chrome and wasn’t able to find anything.


  • Definitely not, I do the same.

    I installed 64 GB of RAM in my Windows laptop 4 years ago and had been using 64 GB of RAM in the laptop that it replaced - which was from 2013 (I think I bought it in 2014-2105). I was using 32 GB of RAM prior (on Linux and Windows laptops), all the way back to 2007 or so.

    My work MacBook Pros generally have 32-64 GB of RAM, but my personal MacBook Air (the 15” M2) has 16 GB, simply because the upgrade wasn’t a cost effective one (and the M1 before it had performed great with 16) and because I’d only planned on using it for casual development. But since I’ve been using it as my main personal development machine and for self-hosted AI, and have run into its limits, when I replace it I’ll likely opt for 64 GB or more.

    My Windows gaming desktop only has 32 GB of RAM, though - that’s because getting the timings higher with more RAM - particularly 4 sticks - was prohibitively expensive when I built it, and then when the cost wasn’t a concern and I tried to upgrade, I learned that my third and fourth RAM slots weren’t functional. I could upgrade to 64 GB in two slots but it wouldn’t really be worth it, since I only use it for gaming.

    My Linux desktop / server has 128 GB of ECC RAM, though, because that’s as much as the motherboard supported.


  • I haven’t personally used any of these, but looking them over, Tipi looks the most encouraging to me, followed by Yunohost, based largely on the variety of apps available but also because it looks like Tipi lets you customize the configuration much more. Freedom Box doesn’t seem to list the apps in their catalog at all and their site seems basically useless, so I ruled it out on that basis alone.


  • I am trying to avoid having to having an open port 22

    If you’re working locally you don’t need an open port.

    If you’re on a different machine but on the same network, you don’t need to expose port 22 via your router’s firewall. If you use key-based auth and disable password-based auth then this is even safer.

    If you want access remotely, then you still don’t have to expose port 22 as long as you have a vpn set up.

    That said, you don’t need to use a terminal to manage your docker containers. I use Portainer to manage all but my core containers - Traefik, Authelia, and Portainer itself - which are all part of a single docker compose file. Portainer stacks accept docker compose files so adding and configuring applications is straightforward.

    I’ve configured around 50 apps on my server using Docker Compose with Portainer but have only needed to modify the Dockerfile itself once, and that was because I was trying to do something that the original maintainer didn’t support.

    Now, if you’re satisfied with what’s available and with how much you can configure it without using Docker, then it’s fine to avoid it. I’m just trying to say that it’s pretty straightforward if you focus on just understanding the important parts, mainly:

    • docker compose
    • docker networks
    • docker volumes

    If you decide to go that route, I recommend TechnoTim’s tutorials on Youtube. I personally found them helpful, at least.



  • I’m not addressing anything Gitea has specifically done here (I’m not informed enough on the topic to have an educated opinion yet), but just this specific part of your comment:

    And they also demand a CLA from contributors now, which is directly against the idea of FOSS.

    Proprietary software is antithetical to FOSS, but CLAs themselves are not, and were endorsed by RMS as far back as 2002:

    In contrast, I think it is acceptable to … release under the GPL, but sell alternative licenses permitting proprietary extensions to their code. My understanding is that all the code they release is available as free software, which means they do not develop any proprietary softwre; that’s why their practice is acceptable. The FSF will never do that–we believe our terms should be the same for everyone, and we want to use the GPL to give others an incentive to develop additional free software. But what they do is much better than developing proprietary software.

    If contributors allow an entity to relicense their contributions, that enables the entity to write proprietary software that includes those contributions. One way to ensure they have that freedom is to require contributors to sign a CLA that allows relicensing, so clearly CLAs can enable behavior antithetical to FOSS… but they can also enable FOSS development by generating another revenue stream. And many CLAs don’t allow relicensing (e.g., Apache’s).

    Many FOSS companies require contributors to sign CLAs. For example, the FSF has required them since 2005 at least, and its CLA allows relicensing. They explain why, but that explanation doesn’t touch on why license reassignment is necessary.

    Even if a repo requires contributors sign a CLA, nobody’s four freedoms are violated, and nobody who modifies such software is forced to sign a CLA when they share their changes with the community - they can share their changes on their own repo, or submit them to a fork that doesn’t require a CLA, or only share the code with users who purchase the software from them. All they have to do is adhere to the license that the project was under.

    The big issue with CLAs is that they’re asymmetrical (as opposed to DCOs, which serve a similar purpose). That’s understandably controversial, but it’s not inherently a FOSS issue.

    Some of the same arguments against the SSPL (which is not considered FOSS because it is so copyleft that it’s impractical) being considered FOSS could be similarly made in favor of CLAs. Not in favor of signing them as a developer, mind you, but in favor of considering projects that use them to be aligned FOSS principles.