Just a basic programmer living in California

  • 11 Posts
  • 117 Comments
Joined 1 year ago
cake
Cake day: February 23rd, 2024

help-circle
  • I’m not a lawyer either. But going off the company store insight, maybe we can look to the Fair Labor Standards Act of 1938. It prohibits paying wages in scrip, or “similar devices”. Scrip can take a couple of forms; one is an internal company currency that can only be spent at the company store. That provision in the FLSA was specifically intended to shut down company store scams.

    It seems that an implied condition of your work is spending some portion of your wages at certain stores. Since scrip is money that can only be spent in certain places, it might be argued that if you are required to spend a portion of your wages in certain places, that has the same effect as paying a portion of your wages in scrip.

    Unfortunately after a bit of searching I haven’t seen this specific argument made. But again, I’m not a lawyer, and I don’t know how to research case law. It sounds like they’re trying to claim this program in optional, so it might be challenging to prove that participation is de facto mandatory. I’m guessing if you could get someone to tell you a number for how much they expect you to spend in this program that would help with such an argument. On second thought, I don’t actually know how helpful a number would be, and I don’t want to get you in trouble.



  • That’s a good point! The string is in there, and I can see it with strings. But in my research so far it’s looking like making a simple string substitution might not be an option. The replacement string would be a Nix store path which would be longer. That would shift over subsequent bytes in the binary which it sounds like would produce alignment issues that would break things.

    Apparently it’s ok to change the length of the ELF header, which is what patchelf does. But shifting bytes in the ELF body is a problem.

    Now what I haven’t verified yet is whether the embedded binary is in the body or in the header. If it’s in the header - or even if just the interpreter string is in the header then I might be good to go.










  • This is a big reason for me. Also because if anything breaks - even if my system becomes unbootable - I can select the previous generation from the boot menu, and everything is back to working.

    It’s very empowering, the combination of knowing that I won’t irrevocably break things, and that I won’t build up cruft from old packages and hand-edited config files. It’s given me confidence to tinker more than I did in other distros.



  • Thinking out loud, I think the reason those salons became famous is because the participants published, and their publications got a lot of attention. An example that springs to my mind is the Vienna Circle. But maybe a better example is Madame Geoffrin’s salon which hosted French nobles and Enlightenment thinkers. In that case too the attendees either published, or were powerful figures in society.

    The format is a smallish group of people discussing ideas, probably with some connecting theme. It seems like historically those themes were broad, like “philosophy”, with a focus on debate. If some of the people involved turn out to be important to society you’ve got yourself a historically-significant organization. If not then hopefully everyone had a good time.



  • My wife has worked with lots of people who are not native English speakers who are sometimes taken aback by the idioms. One colleague flat out refused to accept that “FOMO” is a word.

    I suggested that she is in a position to make some up, like “Let’s not put fish in the milk bucket.” But she didn’t go for it. I guess she’s not an agent of chaos after all :/





  • It seems to me that you’re asking about two different things: zero-knowledge authentication, and public key authentication. I think you’d have a much easier time using public key auth. And tbh I don’t know anything about the zero-knowledge stuff. I don’t know what reading resources to point to, so I’ll try to provide a little clarifying background instead.

    The simplest way to a authenticate a user if you have their public key is probably to require every request to be signed with that key. The server gets the request, verifies the signature, and that’s it, that’s an authenticated request. Although adding a nonce to the signed content would be a good idea if replay attacks might be a problem.

    If you want to be properly standards-compliant you want a standard “envelope” for signed requests. Personally I would use the multipart/signed MIME type since that is a ready-made, standardized format that is about as simple as it gets.

    You mentioned JSON Web Tokens (JWTs) which are a similar idea. That’s a format that you might think you could use for signing requests - it’s sort of another quasi-standardized envelope format for signed data. But the wrinkle is that JWTs aren’t used to sign arbitrary data. The data is expected to be a set of “claims”. A JWT is a JSON header, JSON claims, and a signature all of three which are serialized with base64 and concatenated. Usually you would put a JWT in the Authorization header of an HTTP request like this:

    Authorization: Bearer $jwt
    

    Then the server verifies the JWT signature, inspects the “claims”, and decides whether the request is authorized based on whether it has the right claims. JWTs make sense if you want an authentication token that is separate from the request body. They are more complicated than multipart/signed content since the purpose is to standardize a narrow use case, but to also support all of the features that the stakeholders wanted.

    Another commenter suggested Diffie-Hellman key exchange which I think is not a bad idea as a third alternative if you want to establish sessions. Diffie-Hellman used in every https connection to establish a session key. In https the session key is used for symmetric encryption of all subsequent traffic over that connection. But the session key doesn’t have to be an encryption key - you could use the key exchange to establish a session password. You could use that temporary password to authenticate all requests in that session. I do know of an intro video for Diffie-Hellman: https://youtu.be/Ex_ObHVftDg

    The first two options I suggested require the server to have user public keys for each account. The Diffie-Hellman option also requires users to have the server’s public key available. An advantage is that Diffie-Hellman authenticates both parties to each other so users know they can trust the server. But if your server uses https you’ll get server authentication anyway during the connection key exchange. And the Diffie-Hellman session password needs an encrypted connection to be secure. The JWT option would probably also need an encrypted connection.


  • hallettj@leminal.spacetoLinux@lemmy.mlHow do you backup?
    link
    fedilink
    English
    arrow-up
    3
    ·
    2 months ago

    My conclusion after researching this a while ago is that the good options are Borg and Restic. Both give you incremental backups with cheap timewise snapshots. They are quite similar to each other, and I don’t know of a compelling reason to pick one over the other.