111–120 of 191 posts
Earlier quoted context omitted.
I agree Git can be complex, but... CVS? Really? I do not miss non-atomic commits at all .
The point is that for OpenBSD that security trumps anything else, including usability of developer tools.
Should programs periodically check for critical security fixes, and then refuse to run if the current version is affected? It seems like there are a lot of people who don't really pay attention to social media or other security alert channels, who won't have a clue about the extent of this vulnerability. I'm sure they'd update if they knew "if I clone a malicious repo, I'm toast," but there's no way to inform them ex…
I'm not sure how I feel about programs phoning home like that. I tolerate it with apps, but command line tools ought to be doing their stated function when run.
Maybe even a push update you can subscribe to.
Ouch! And I thought the OpenBSD people were paranoid for sticking with CVS. (because Git is too bloated and complex in their view, so they weren't able to review it thoroughly, which would have been the only way for them to trust it.) I always get a strange, uneasy feeiling when the tin foil hats turn out to be right. I wonder if they are right on GPG, too. For those who don't know this: The OpenBSD people refuse to…
Ridiculously enough, this is not always the case (I weep for us).
Should they have known that Windows and MacOS sport case-insensitive filesystems? Definitely.
But, how does this have anything to do with bloat or complexity?
(I am aware of all the - quite frankly ridiculous - complexity of Unicode characters that are visually identical and "should be treated as such for the purposes of comparison", but I think that's another example of excess complexity leading to things like directory-traversal attacks.)
Maybe alert banners aren't in the git-scm.com css template.
edit: Is it that I'm on Linux? I changed a few UAs but the download image still reads "Downloads for Linux".
Homebrew just updated ( https://github.com/Homebrew/homebrew/pull/35105 ), so Homebrew users should be covered by brew update && brew upgrade git
And don't copy&paste the above code into the terminal! (Potential vulnerability, though HN is probably safe.)
Earlier quoted context omitted.
You can at least in theory inspect the library code after cloning it but before compiling it. Insta-owning your machine just because you cloned it is considerably worse. This is especially true if you always run the library in a sandbox of some sort (e.g. you're building an Android app and your code always runs on an Android device or emulator).
With Android apps you still build locally, typically with Gradle, allowing arbitrary code execution on the host.
Ouch! And I thought the OpenBSD people were paranoid for sticking with CVS. (because Git is too bloated and complex in their view, so they weren't able to review it thoroughly, which would have been the only way for them to trust it.) I always get a strange, uneasy feeiling when the tin foil hats turn out to be right. I wonder if they are right on GPG, too. For those who don't know this: The OpenBSD people refuse to…
Git devs made the incorrect assumption that saving .giT/cONFIg to disk, would actually save .giT/cONFIg to disk. Ridiculously enough, this is not always the case (I weep for us). Should they have known that Windows and MacOS sport case-insensitive filesystems? Definitely. But, how does this have anything to do with bloat or complexity?
On Windows, certain path components that are different from ".git"
are mapped to ".git", e.g. "git~1/config" is treated as if it were
".git/config". HFS+ has a similar issue, where certain unicode
codepoints are ignored, e.g. ".g\u200cit/config" is treated as if
it were ".git/config"