Cursed knowledge we have learned as a result of building Immich that we wish we never knew.
-
I ... this seems like a std library made to troll you. Is there a (good) reason it is like that?
early js/html liked to do something in all cases instead of throwing or whatever. I think it's mostly just a collection of them trying to do something smart on nonsense input and not being consistent about it.
side note, I'm so excited for Temporal, some browsers already support it and you can polyfill for the rest.
-
This post did not contain any content.wrote last edited by [email protected]
The bcrypt implementation only uses the first 72 bytes of a string. Any characters after that are ignored.
what
-
The bcrypt implementation only uses the first 72 bytes of a string. Any characters after that are ignored.
what
This is how someone cracked Okta a few years back: https://medium.com/@rajat29gupta/bcrypt-and-the-okta-incident-what-developers-need-to-know-9d13a446738a
-
The bcrypt implementation only uses the first 72 bytes of a string. Any characters after that are ignored.
what
wrote last edited by [email protected]Older Unix systems used to only do the first 8 bytes for passwords. Sometimes for my own amusement when logging into one of the Sun machines at school, I'd type in enough of my password to count and then just mash the keyboard.
-
It doesn't matter. That will happen for both the stored hash and the entered password, so it still matches.
As long as it runs the same code, yes. But things may change, clients may pre-emptively split the string or stuff like that.
-
Some phones will silently strip GPS data from images when apps without location permission try to access them.
This is quite reasonable.
It is not. App X creates image A with location data.
App Y without location permission accesses image A in read mode. Now image A has no location.
You open image A again from app X and the location is no longer there. It makes no sense. Had app Y written to image A, it makes sense that location data was stripped. But opening a file in read mode should not alter it. Except for metadata of the kind "last opened at ...".
-
This post did not contain any content.
Some web features like the clipboard API only work in "secure contexts" (ie. https or localhost)
I think that's reasonable behavior
-
It is not. App X creates image A with location data.
App Y without location permission accesses image A in read mode. Now image A has no location.
You open image A again from app X and the location is no longer there. It makes no sense. Had app Y written to image A, it makes sense that location data was stripped. But opening a file in read mode should not alter it. Except for metadata of the kind "last opened at ...".
In modern android you do not open files, you use an OS service to get an image, which may or may not come from a file on the device. If you want to open files you need a different permission.
You could argue that android should have a permission level for apps that need image geolocation but not GPS.
-
In modern android you do not open files, you use an OS service to get an image, which may or may not come from a file on the device. If you want to open files you need a different permission.
You could argue that android should have a permission level for apps that need image geolocation but not GPS.
One could argue they a reading service should not alter the thing that's read. Android is not a quantum state!
-
I ... this seems like a std library made to troll you. Is there a (good) reason it is like that?
Backward compatibility and not seeing the future. Some decisions are taken at one point in time, then a new use case show up, then a new paradigm evolve, then… etc etc.
It's really the same thing that holds back a lot of languages and libraries. And even when replacement shows up, old habits from devs and old projects maintenance keep all these things well alive too.
