• 0 Posts
  • 46 Comments
Joined 2 years ago
Cake day: July 14th, 2023
  • hedgehog@ttrpg.networktoLinux@lemmy.ml•Immich 1.136 Photo and Video Backup Brings Breaking Changes
    3·
    16 days ago

    I genuinely don’t understand why people here are taking it so hard that I wish the Immich devs were using semver.

    Because you didn’t say that; you said “Breaking changes in a point release? Not cool” and later “I’m basing this off the guidelines at semver.org.”

    I’m paraphrasing your comments from memory, to be clear, so apologies if I misquoted you.

    It certainly felt to me like you were assuming that this project was using semver and was not following it well, not that you wouldn’t want to use a project that receives this many breaking changes / that doesn’t follow semver. Those complaints both make a lot more sense to me - and I’ve seen many people say similar things about Immich in the past. In fact, it’s a big part of why I haven’t migrated from Photoprism to Immich myself - in this regard they’re complete opposites.

  • hedgehog@ttrpg.networktoLinux@lemmy.ml•Immich 1.136 Photo and Video Backup Brings Breaking Changes
    3·
    16 days ago

    I don’t think there’s any room to argue that announcing a 1.x with a change the developers say is a breaking change, which is what Immich have done, fits within the semver.org guidelines.

    That wasn’t the argument.

    Following semver is optional. If a project doesn’t explicitly state it is following semver, it shouldn’t be assumed that it is. With regard to Immich in particular, a cursory review of their documentation makes it clear that they are not following semver. Literally, go to https://immich.app/ and read the text at the very top of the page:

    ⚠️ The project is under very active development. Expect bugs and changes.

    Go to the repo and you’ll see the README, which states at the very top:

    • ⚠️ The project is under very activedevelopment.
    • ⚠️ Expect bugs and breaking changes.

    If you can read that, see that they’re on major version 1 with a minor version over 100, and you still think they’re using semver, then that’s on you.

    The devs have stated they won’t be using semver until they consider Immich production ready, and that moving to a 1.x version from 0.x was a mistake made some time ago. If you want to think about it as though it is semver, consider the major version to still be 0. See https://github.com/immich-app/immich/discussions/5086#discussioncomment-7593227 for example.

    As this project is clearly not following semver, the semver guidelines aren’t applicable and haven’t been violated.

    I don’t think there’s any room to argue

    Even if semver were applicable, in this case, I would still disagree. The text from semver.org states:

    8. Major version X (X.y.z | X > 0) MUST be incremented if any backward incompatible changes are introduced to the public API.

    It doesn’t state that any backward incompatible changes, period, require a major version increase, only changes to the public API. I would personally argue that the deployment configuration is part of the public API, but not all project owners agree with me. Even if they do agree, they might say that this was not a documented deployment configuration and thus not part of the public API, and that it therefore doesn’t necessitate an increase to the major version, but as they knew that people were using that configuration, anyway, they included a note about a potentially breaking change as a courtesy to those users.

  • hedgehog@ttrpg.networktoLinux@lemmy.ml•Fedora threatened with legal action from OBS Studio due to their Flatpak packaging
    1·
    6 months ago

    They put their repo first on the list.

    Right. And are we talking about the list for OBS or of repos in general? I doubt Fedora sets the priority on a package level. And if they don’t, and if there are some other packages in Flathub that are problematic, then it makes sense to prioritize their own repo over them.

    That said, if those problematic packages come from other repositories, or if not but there’s another alternative to putting their repo first that would have prevented unofficial builds from showing up first, but wouldn’t have deprioritized official, verified ones like OBS, then it’s a different story. I haven’t maintained a package on Flathub like the original commenter you replied to but I don’t get the impression that that’s the case.

  • hedgehog@ttrpg.networktoSteam Deck@sopuli.xyz•[PSA] The terrible tragedy of a stolen Steam Deck
    3·
    1 year ago

    They have no recourse

    They can do all of the following:

    1. Report the seller to the platform for selling stolen goods.
    2. Return the stolen goods to the rightful owner, if they’re able to get their information, or if not, to Valve or even just the police department.
    3. File a suit in small claims court against the seller for damages (the amount they paid + any other expenses they’ve incurred, like the cost to mail it to the rightful owner, including legal fees) or, if the platform won’t provide the seller’s information, against the platform itself.
  • hedgehog@ttrpg.networktoLinux@lemmy.ml•How to prevent files from being displaced? This protection should (somehow) persist through disk cloning.
    2·
    1 year ago

    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.

  • hedgehog@ttrpg.networktoLinux@lemmy.ml•How to prevent files from being displaced? This protection should (somehow) persist through disk cloning.
    5·
    1 year ago

    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.”