Hacker Newsnew | past | comments | ask | show | jobs | submit | Liquid_Fire's commentslogin

It's not factually wrong, but it implies that this is something specific to Git, and possibly might even be interpreted that it is Git's fault.

In reality it's macOS shipping the outdated certificates, and it affects various other command-line tools, like Curl.


Fair. I didn't read it as something specific to git cause I know how it works with MacOS

Not macOS, but XCode dev tools. Still, it is Apple that ships them for sure.

Does /etc/ssl/cert.pem not exist if you don't install XCode?

It's certainly possible, but I'd say the evidence fits the opposite explanation more: if it was not for business purposes, why do it on your work machine, during working hours, with your work email address in the User-agent?

> it seems plausible to hit by mistake

The report seems to claim the opposite:

> Looking at the bug itself, it is also very likely that this unsoundness has not caused memory unsafety by accident. While it looks easy to trigger, to exploit this you need an intentionally malicious Drop implementation.


This edit is newer than my comment (and its writer is an experienced T-types member, so I take back my words).


I'm happy to admit I don't really know what I'm talking about with this bug, however the ability to leak memory is pretty demonstrable, no? The OP's example of using a global cache with Drop seems a bit gross... but that hasn't ever stopped C devs lol (as a proud C dev myself).

I guess my take is that I'd rather assume this is exploitable in the wild until sufficient time has passed. Would be cool to see clippy pick up on this bug in older versions!


> however the ability to leak memory is pretty demonstrable, no?

This bug wouldn't be nearly as interesting if it "just" resulted in a memory leak. Memory leaks aren't considered unsafe in Rust because they can't result in UB in the same way as e.g., OOB writes. In fact, there are APIs accessible in safe Rust which explicitly leak memory! [0]

This bug is effectively a use-after-free, which is definitely something that the Rust compiler should catch.

> Would be cool to see clippy pick up on this bug in older versions!

No need for that. A future version of the Rust compiler that incorporates a fix should reject the incorrect code, so all you'd need to do is compile older code with that new compiler.

[0]: https://doc.rust-lang.org/std/mem/fn.forget.html


> however the ability to leak memory is pretty demonstrable

It is, but safe Rust merely makes it hard to do by accident. Leaking is not "memory unsafe" because is does not currupt anything, so it's legal.


Sorry, can you clarify about Microsoft having adopted \n? This is the first time I hear of it, and I can't find anything online about it.


It’s not a consistent change, but for example programs like notepad couldn’t handle \n, but do accept it now. Visual Studio expects certain file types to use \r\n, but accepts others like .gitignore using \n.

Same thing for \ and / in path separators: Microsoft never made a consistent push for it, and it depends on the application.


I'm not sure I would call that "adoption", so much as "compatibility with", since the default line ending produced by Windows software is still almost always \r\n for files created from scratch.


FWIW I think it's a fair point. My view of this is as an outsider only seeing what comes in for review from Windows-using colleagues so maybe I overstated the level of adoption.


I believe git has a setting to auto-convert to CRLF on checkout and back to LF on commit, so that could also be partially to blame.


I also tried VS code and found that you can configure it to output just the line feed. You could also configure it to append a "trailing newline" which cause an empty line to be inserted at the end upon save. This practically produces valid POSIX text files, though if I wanted to have an empty line at the end of my document it can't tell the difference between that and the so-called "trailing newline".

It ultimately also doesn't really present these files correctly. The last LF is still presented as an empty line at the end of the document. Someone reported that, and they added the option to hide the "trailing newline" to address it, but it effectively only stops displaying it, while you can still navigate to it. I ended up reporting simply that it doesn't handle POSIX text files correctly, describing the problem and the issues with the current attempts at solutions, but it was classified as a feature request and eventually closed due to losing some kind of popularity contest they have for these.

Seemed like such a basic function for a text editor and a dysfunctional response to my report, so quickly gave up on using it.


That seems impossible (unless maybe you meant to write "predates", and even then it seems to only be about 3 years).

The comic was published on 9 February 2007 [0].

The PS3 was first released in November 2006. I haven't watched the video yet, but its description says "2010 saw the first hacks for the Playstation 3".

[0] https://xkcd.com/221/info.0.json


I believe this has been around for a while; it's probably just been rolled out to more regions (Germany, France, and Italy, according to the article).

It's annoying, but thankfully it's a single checkbox in the settings to disable it (uncheck "Suggestions from sponsors").


> Note: Certain parts of Firefox Suggest are currently available only in some regions.

https://support.mozilla.org/en-US/kb/firefox-suggest


100 W sockets? All the flights I've been on that provided power have had a really low current USB A port that can barely keep my phone from discharging when the screen is on.


Try traveling abroad with a prepaid data SIM (or limited roaming data allowance).

Plenty of websites already have comically huge pointless images (often then scaled down to tiny sizes for display). No need to make the problem worse.


Even though it's called "T9 Speed Test", it seems to default to T9 being off, and you have to actually click on the T9 link at the top right to enable it. Really confusing at first!


It's not real Python. It's essentially a made-up language that resembles a subset of Python.

That said, if I was building a small ugly toy Python implementation, I would probably also not implement long integers. Or the power operator. At least not in the first iteration.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: