Please note that some commits may be excluded from this release if they’re not relevant, or not modifying the GuestOS image. Additionally, descriptions of some changes might have been slightly modified to fit the release notes format.
To see a full list of commits added since last release, compare the revisions on GitHub.
Features:
23af050fb Crypto,Interface(crypto): Support key derivation in ic_crypto_ecdsa_secp256k1 (#706)
951e895c7 Execution,Interface: Handle stable_read/write with Wasm64 heaps and testing infrastructure (#781)
The two SHA256 sums printed above from a) the downloaded CDN image and b) the locally built image, must be identical, and must match the SHA256 from the payload of the NNS proposal.
This commit makes the default dkg-interval-length 499 instead of 199, which is inline with recent subnet management proposals (131699 is currently the last open proposal that needs to be executed for all subnets to have a dkg-interval-length of 499).
I believe this commit affects GuestOS given that it alters the initialisation of SubnetConfig which is utilised by GuestOS, and therefore should have been included in this proposal’s change log - unless I’m mistaken.
It’s interesting that a modification to the ingress message verifier was recently included in a GuestOS proposal (this commit → b029bf49b on this proposal change log → 124487). Ingress message verification/validation is surely a responsibility of GuestOS, but it perhaps no longer uses this component (whereas it once did…) is that right, or am I still misunderstanding?
Thanks for looking into this other case. There appear to be numerous source files under /rs/execution_environment/ that utilise this object (/rs/execution_environment/benches/lib/src/common.rs is an example). The CODEOWNERS file indicates that these files are the responsibility of the execution-owners and runtime-owners team, which are both recognised as replica teams.
There are no shortage of examples where bazel recognises components as GuestOS dependencies even when they have no chance of modifying GuestOS behaviour (and can therefore arguably be wrong, in real terms). Is it conceivable that under certain circumstances bazel could fail to recognise certain dependencies and/or filter them out for some reason?
I think it was never used and it was just included in previous changelog because we didn’t qualify bazel targets properly before this change.
The former is quite easy to occur. One could just add a random dependency to GuestOS even if no code ever called that dependency and then bazel would have to say that package is a dependency. The opposite I cannot imagine. It would mean that Bazel is somehow utilizing that code to build the GuestOS but saying it’s not. Due to sandboxing in bazel, this would be impossible (i.e. only packages that are explicitly added as dependencies can be used to build the target). It’s still possible if we have bugs in the code that’s querying Bazel and we obviously had bugs as we’ve seen above. That of course wouldn’t be fault of Bazel.
Thanks for taking a look. I’ve had a peek at the change to release_notes.py. There’s various refactoring, such as making the bazel query an argument of bazel_query rather than defined within the function (but ultimately the query looks the same). It’s not immediately clear to me what the ‘qualify bazel targets properly’ fix aspect of this commit is.
Interesting that a hardcoded list of bazel_packages_all is added (this looks a little brittle, how is this kept up-to-date? ).
In any case, I gather that bazel recognised the ingress message verifier commit as modifying a GuestOS dependency. You’re saying it should have been filtered out as a ‘hard’ or ‘soft’ exclusion by the release notes generator - is that correct? Otherwise I’m not sure how it was considered for inclusion in the first place.
Thanks @Luka, this comment got me thinking (more generally, rather than specifically about this release)… If I were a DFINITY engineer or an external contributor (in a hopeful future where IC-OS modifications from external contributors may occur), and I wanted to try and slip some GuestOS changes under the wider community’s radar. Couldn’t I just do this:
Modify a source code file or set of files
Reset the file metadata so that the modification timestamps are unchanged
Wait, knowing that these sneaky changes will likely go unnoticed by bazel (assuming checksum caching), and therefore also likely unnoticed by the wider community
Much later, to action my sneaky changes, I make a simple, justifiable, and unrelated change to those same files, simply to trigger bazel to rebuild GuestOS with those updated files (now including my old sneaky changes as well that were previously ignored)
Aren’t the above steps a conceivable way of modifying GuestOS without those commits being included in the GuestOS change log that’s published with the proposal?
^ sorry this was a brain fart! The build wouldn’t be reproducible, because the file modification timestamp would be set for others based on when the changes were pulled from origin.
We previously tried to assign a file change to a package based on guestos dependencies list, instead of all. so some file changes were assigned to incorrect packages.
this is unfortunate limitation of testing this. i didn’t figure out how to run bazel binary within bazel test so i had to hardcode it. but this is just a test, and test is pinned to a specific commit, so it should be fine.
specifically, we wrongly assigned lots of file changes to rs package, whereas it should’ve been some subpackage. and since rs package is in dependency list of guestos, we ended up not hard excluding lots of commits.
any software can have bugs of course
i think in this specific case our notes changelog wouldn’t be affected but maybe building the guestos would. proper dependency and sanbdoxing is a core feature of bazel, so any bugs like this seem highly unlikely to happen in the future and seems like a bad use of effort to engineer changelog generation accounting for bazel build bugs. correct changelog with a wrong build doesn’t make much sense.
but it perhaps no longer uses this component (whereas it once did…) is that right, or am I still misunderstanding?
The build wouldn’t be reproducible, because the file modification timestamp would be set for others based on when the changes were pulled from origin.