I realise that a good portion of the references to the product on that page is just "Microsoft 365", but other parts seem to include "Copilot" in the product name for Microsoft's office suite.
This reminds me of the PIK image format (a precursor to JPEG XL) whose name happens to be a word for penis in some languages[0]. In the present case "SPH" is a kink/fetish term meaning "Small Penis Humiliation"[1]. I don't know how many people would think of that, though.
I am not sure if the lesson is to try harder to avoid offence, or live with the fact that words can have multiple meanings and we can be "professional" enough to ignore some of those meanings in some contexts.
It seems like that will change in the (near) future according to the following github issue[0]. A quote from one of the developers, rami3l, in that thread[1]:
> My current plan is indeed to remove implicit installations entirely.
Oh sad! Dang I actually really liked the feature, it's super convenient for keeping developer environments in sync. I left a comment in that thread asking for clarification.
>> Oh sad! Dang I actually really liked the feature, it's super convenient for keeping developer environments in sync. I left a comment in that thread asking for clarification.
Here is a slightly contrived, but realistic example of why it is a bad idea:
1) Attacker discovers vulnerability in an older version of the Rust toolchain
2) Attacker creates useful crate and helps it to get widely adopted or becomes trusted contributor to a crate that is already popular
3) Attacker creates and publishes crate changes with exploit code and rust-toolchain.toml to trigger use of older, vulnerable Rust toolchain
4) Unsuspecting developers build the trapped crate or something that depends on it and get owned
Installing toolchains automatically without the user's consent or permission is a supply chain attack in waiting for both Rust and Go.
Perhaps they could make it a configuration setting that developers could opt-in? That would let developers who want automatic toolchain installs to have it and others who do not want it (or whose employers will not allow it) to not have it.
In Go case though the version can only go higher, not lower (e.g.: it will not download a toolchain if the Go version is set to lower than your current one, only higher). So I can't see the same attack being executed here.
>> In Go case though the version can only go higher, not lower
That is good to know, assuming that the newer hypothetical toolchain is not vulnerable (e.g. a zero-day in the newer toolchain).
My opinion is still that toolchains (newer or older) should not be implicitly installed without the developer's explicit permission. This could be a configuration setting that the developer has opted-in or a "This package requires toolchain version X. Install it? (y/n)" prompt.
> That is good to know, assuming that the newer hypothetical toolchain is not vulnerable (e.g. a zero-day in the newer toolchain).
This would still be really difficult to explore:
0. An undiscovered zero-day in the newest version of Go
1. The only way to force users to use the newest toolchain is if your project has dependencies where the attacker has control, so e.g.: they can change their go.mod and set a `go` directive that upgrades to the later version
2. You need to update to this new version, because this will make Go complain that your `go` directive inside your `go.mod` is out-of-date
3. After all this, yes, Go will download the newest version of Go (that is vulnerable)
But I would argue if the attacker already has 2, they have better ways to attack you (e.g.: they can add code to `init()` that will run once the module is imported, and this could be explored once you build and run the binary).
Again, not saying that this is an impossible scenario, just find it highly unlikely.
> This could be a configuration setting that the developer has opted-in or a "This package requires toolchain version X. Install it? (y/n)" prompt.
I concur at this part though, however keep in mind that this `toolchain` feature is more akin to adding a module dependency, since it reuses the whole module system.
I think there is already lots of trust that is implicit when you are managing modules, and this new feature doesn't make it worse. If anything, considering that the binaries can only come from golang.org/toolchain and I assume Go already check the checksum of every module that it downloads (and also that Go is perfectly reproducible: https://go.dev/blog/rebuild), if anything this is probably more trusted than a random module that you add to your project.
Thanks, I understand this; but what I don't understand is, wouldn't it be easier for the same attacker to do the same thing by exploiting a vulnerability in a different crate, and include that other crate as a dependency?
As for configuration: to me, having it be opt-in negates the entire benefit. My point is that automatically installing the correct toolchain makes it far easier to collaborate with others who aren't nearly as obsessive about Rust as I am.
>> wouldn't it be easier for the same attacker to do the same thing by exploiting a vulnerability in a different crate, and include that other crate as a dependency?
Possibly, which is why the example is a bit contrived. In most cases, the toolchains will likely be more trusted and be on approved lists whereas binaries created by third-party crates are not.
For more secure environments, explicitness is valued and automatic installation of anything is frowned upon because it can introduce unvetted changes which could include vulnerabilities.
It depends on what work is being done and how much toolchains and ecosystem can be trusted.
>> That seems like a lot of hoops to jump through considering that rust allows arbitrary code execution during compile time anyway.
If you mean build.rs build scripts, yes, those do run, but it is not arbitrary code. You can view and inspect them before building. If you need more security, you can download all the dependencies and build inside an isolated container.
You can't post like this here, so I've banned the account.
If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html.
Sorry for being off topic, but what is going on with the timestamps of this paper?
The latest version (version 2) has 2018-05-28 as the date above the abstract, but it was added to arxiv on 2014-12-15. Version 1 has the date 2022-05-18, but was added to arxiv on 2010-10-29. I briefly skimmed the .tex source file, but I couldn't find any explanation of the date in there. Did someone mess with the clock on the build server?
I would say that the instance (or second long interval) in time that we name 2016-12-31T23:59:60Z is 1483228836 seconds after 1970-01-01T00:00:00Z, and that 2017-01-01T00:00:00Z is 1483228837 seconds after 1970-01-01T00:00:00Z [0].
The key here is that I use "seconds" to mean a fixed duration of time, like how long it takes light to travel 299792458 meters in a vacuum[1], and this version of seconds is independent of Earth orbiting the Sun, or the Earth spinning or anything like that[2].
If I understand you correctly, you use "seconds" more akin to how I use "days in a year": Most years have 365 days, but when certain dates starts to drift too far from some astronomical phenomenon we like to be aligned with (e.g. that the Northern Hemisphere has Summer Solstice around the 21st of June) we insert an extra day in some years (about every 4th year).
I haven't read RFC 9562 in detail, but if you use my version of "seconds" then "seconds since the Epoch" is a meaningful and monotonically increasing sequence. I suspect that some of the other commentors in this thread use this version of "seconds" and that some of the confusion/disagreement stems from this difference in definition.
The paragraph in Section 6.1 titled "Altering, Fuzzing, or Smearing" also seems relevant:
> Implementations MAY alter the actual timestamp. Some examples include ..., 2) handle leap seconds ...
> This specification makes no requirement or guarantee about how close the clock value needs to be to the actual time.
[0] Please forgive any off-by-one errors I might have made.
[1] I know that the SI definition between meters and seconds is the other way around, but I think my point is clearer this way.
[2] I ignore relativity as I don't think it is relevant here.
When I used that term in my last comment, I specifically meant the timescale formally defined by POSIX and linked above, which it misleadingly calls "seconds since the Epoch". This is the timescale people usually mean by "Unix time", and it's what UUIDv7 aspires to align to: in its own words, it's "derived from the widely implemented and well-known Unix Epoch timestamp source".
But Unix time isn't a count of SI seconds, as you might wish it to be. Instead, it's effectively "the number of whole days between 1970-01-01 and UTC-today, times 86400, plus the number of SI seconds since the last UTC-midnight." It smashes each UTC day into 86400 'seconds', regardless of whether it is truly longer or shorter due to leap seconds. This makes Unix time non-monotonic at the end of a leap second, since it rolls back that second at the following midnight.
It's nice that the RFC mentions leap seconds at all, but it's really playing with fire to leave it so vague, when monotonicity is an especially important property for these UUIDs. Its brief definition of the UUIDv7 time source as "the number of milliseconds since midnight 1 Jan 1970 UTC, leap seconds excluded" especially doesn't help here, because the discrepancies in UTC are even worse than leap seconds:
> I would say that the instance (or second long interval) in time that we name 2016-12-31T23:59:60Z is 1483228836 seconds after 1970-01-01T00:00:00Z, and that 2017-01-01T00:00:00Z is 1483228837 seconds after 1970-01-01T00:00:00Z [0].
Before 1972, the length of a UTC second was shorter than the length of an SI second. If you account for that, 2016-12-31T23:59:60 UTC is ~1483228827.999918 SI seconds after 1970-01-01T00:00:00 UTC; and 2017-01-01T00:00:00 UTC is ~1483228828.999918 SI seconds after 1970-01-01T00:00:00 UTC. Meanwhile, the "Unix time" (POSIX's "seconds since the Epoch") is 1483228800 for both seconds. (At least, these SI-second intervals are based on the widespread TAI − UTC table [0]. Beware that this table is also inaccurate, in that it was constructed from an older EAL − UTC table using a constant offset, but EAL and TAI continue to run at a different rate due to relativistic effects [1]. Since 1977, EAL − TAI has grown to over 0.00108 SI seconds.)
> I suspect that some of the other commentors in this thread use this version of "seconds" and that some of the confusion/disagreement stems from this difference in definition.
I wish. But the RFC says "leap seconds excluded", and it's designed to align with "Unix time" (which jumps back after every leap second), so clearly it isn't a count of physical SI milliseconds. There's a trilemma here: you can't (a) lie about ("exclude") leap seconds, (b) keep monotonicity, and (c) maintain a constant length of the second, all at the same time; you have to pick two. You yourself would prefer (b) and (c), and POSIX mandates (a) and (c) for "Unix time". But UUIDv7, to align with "Unix time", really wants (a) and (b), which requires smearing, or halting the time scale, or some other dedicated mechanism. Yet the RFC is nearly silent on this.
I am a bit fascinated[1] by the "verified" version, as it fetches from the same URL twice. First I found it inefficient, but since they are doing these request for every zsh startup an extraneous request is probably not seen as a performance problem. Then I realised that the data they verify the hash of is not the same copy of the data that they load: An attacker controlling the server at the curl'ed URL could serve a different file on the second request, which in turn reminded me of a blog post describing how to detect `curl | bash` server side[2][3].
I think the lesson of this small aspect of the "zi" tale is that one should strive to have a single source of truth (a single copy of the data served at the URL), and that in security contexts one needs to be very precise with exactly which guarantees have been established for which data at which point in time: it is surprisingly easy to implicitely add an assumption like "GET requests returning 200 OK behave like pure functions".
[1]: Though this might just be me piling on the mockery of their project, for my own amusement and schadenfreude.
To elaborate, in the Top Chess Engine Championship (which is also used as a benchmark in the AlphaZero vs Stockfish comparison) Stockfish has won all seasons since May 2020[1,2]. A common runner up for those seasons is LCZero[3], which is an engine that is derived from/a reimplementation of AlphaZero. Stockfish is also ahead of LCZero in Fischer random chess (as hosted at TCEC) winning 4 out of the 5 FRC tournaments.
As for how close Stockfish 8 is to a current version of Stockfish, Stockfish 15 has ~400 more ELO than Stockfish 8 as measured in their own self-tests[4].
However, when making these comparisons between AlphaZero and Stockfish it might be tempting to frame it as machine-learning-engine vs classical-engine, which is not true. Stockfish incorporates a neural network when evaluating chess positions[5].
I realise that a good portion of the references to the product on that page is just "Microsoft 365", but other parts seem to include "Copilot" in the product name for Microsoft's office suite.
[0]: https://www.office.com/
reply