• 0 Posts
  • 8 Comments
Joined 1 year ago
cake
Cake day: June 11th, 2023

help-circle


  • I don’t know anything specifically about KeePassXC but it’s my understanding that a transform round is some computationally expensive task that can be preformed as many times as desired, but must be preformed the same number of times to decrypt as well. The point being to slow down any attempts at brute forcing access to you database if someone gets a hold of your encrypted DB file. For example say it takes one second to derive the proper DB access key from the password you entered to unlock the app, that doesn’t really matter to you logging in as almost no one is going to notice a one second delay in logging in. But if some one else gets a hold of your encrypted password DB then they have to wait one second for every password they try, making brute forcing the DB file practically impossible given you’ve chosen an adequate password.

    Ideally you’d choose something which gives a delay not too inconvenient for you when logging in, but enough to thwart the person who might try and brute force the password even if they’re using more powerful hardware.


  • I had a peek at the source code and although I don’t actually know Rust it looks like that error comes from a check for character length in the function “is_valid_body_field”. Strangely it does the same check twice against two variables “POST_BODY_MAX_LENGTH” and “BODY_MAX_LENGTH”.

    The smaller of the two is BODY_MAX_LENGTH which is set at 10000, so I assume the max character limit is 10,000. There are no other checks in that function other than the character count and that’s the only place in the source code that the text “invalid_body_field” shows up so I assume it’s only sent as a response to too much text, but as I said I don’t actually know Rust so I could be wrong.




  • Did you try plugging it in initially after you disassembled it and reassembled it? I’ve found on chromebooks that the embedded controller doesn’t seem to wake up until the charger is plugged in after unplugging the battery. Could it be that you initially didn’t plug it in before trying it months ago, but months later you figured the battery would be low after all that time so you plugged it in finally starting the embedded controller?


  • Interesting about the pic rotation issue. There’s generally two ways that apps handle photo rotation, they either rewrite the file with the new arrangement of pixels or they mark a piece of metadata inside the file to indicate the true orientation. It looks like somewhere in the software chain that orientation metadata is not being respected.

    Lemmy is certainly still having growing pains, hopefully as more people use it and more people choose to develop for it these issues will work themselves out. Until then you might be able to get around that by putting the images though some sort of editing software. Likely most image editors will be able to fix the rotation issue and write the file out with the actual arrangement of pixels necessary to avoid gravity deifying doggos.