Voting is open for a new IC release - 8b674ed

Governance
,
1

Hello there!

We are happy to announce that voting is now open for a new IC release .
The NNS proposal is here: IC NNS Proposal 103281.

Here is a summary of the changes since the last release:

  • 62f97a769 Consensus: fix(consensus): Use notarized_height in most look ahead calculations
  • 3f8b8fe71 Crypto: Add a utility crate for secp256k1 ECDSA signatures
  • 9a2233461 Crypto: chore(crypto): Add Zeroization to the der_utils SecretKeyData struct
  • 07ad0411d Crypto: feat(crypto): Adding metrics for number of iDKG dealing encryption keys in the local public keystore
  • c4b566ac1 Crypto: feat(crypto): crypto service provider can access public key generation timestamps
  • ad563a8fa Crypto: fix: use randomly selected identities in delegation benchmark
  • 163380f93 Execution: feat: Track cycles consumed by ecdsa and http outcalls.
  • ca632904e Message Routing: Do not keep extra checkpoints
  • ea059c9a3 Message Routing: feat: Introduces MetaManifest and handles two kinds of manifest hash
  • c90516350 Message Routing: feat: state_tool supports STATE_SYNC_V2 when verifying manifest
  • 9a278272c Message Routing: fix: Make remove_*_states_below more defensive
  • 680879d2e Networking: docs: Add documentation explaining the different enum values of ReplicaHealthStatus
  • 307f14120 Networking: feat: Increase http outcall request timeout to 30s
  • 66408cf7d Networking: fix: Fixed event_handler_message_duration metric
  • 9da4e8d57 Networking: fix: Use limited body receive when fetching delegation
  • d3fdaf64a Node: Andrew/setup os config read only boot
  • 2e6d2104f Runtime: Fix a panic on MacOS due to Instant subtraction
  • a139ac619 Runtime: Prepare for supporting DTS in heartbeats and timers
  • Various tech-debt management: code refactoring, docs, bug fixes, test updates

And a complete list of changes can of course be found on GitHub.
Please reply to this message if you have any questions or comments.

2 Likes
2

Could you further explain what this means?

3

I tried to build the replica like I did the past couple of weeks and ran into an error with the git checkout of the commit referenced in the proposal. I had the same issue for proposal 103231 that Dfinity executed earlier today. I’m not having trouble repeating the replica build from last week. Do you know why I would have a problem with the git checkout and do you have recommendations for alternate solutions? I provided more info in a post on DSCVR, which shows the error.

Thanks for your help!

3 Likes
4

Off topic perhaps:

Did it build succesfully using only the ./gitlab-ci/tools/docker-build-ic command mentioned in the README?

When I tried to build it stopped at an error executing a .py file, something like “could not get hash of container”

Sorry for not providing details, on my phone. But want to build the damn thing!

5

Yes, I was able to perform the complete build. My initial attempts were to use docker and Ubuntu on WSL2 (windows subsystem for Linux), but this didn’t work. I had to install VirtualBox and use a virtual machine running Linux Ubuntu and docker. That installation works perfectly. I provided more explicit instructions on how I built my builder in a comment on this post on DSCVR.

2 Likes
6

Also not working on my WSL2. Would love to know why.
@sat

Will try virtualbox

7

Hehe, it’s so nice to that community is actively participating and helping to maintain and improve the security.

So what happened is that on Friday we had a security update, and to finish this in the most secure way, we disabled the sync from the private IC repo (in which the CI builds tests) to the public IC repo on github, from which the community gets the source code, etc. As noted in the other thread, the sync has just been re-enabled so pulling changes should again work as expected. Please let me know if you still have issues.

Regarding WSL2 + docker + Ubuntu, maybe @marko has an idea what could be wrong with the setup?

4 Likes
8

@Samer, currently we don’t support building IC artifacts on WSL2. It’s best that you use Ubuntu 20.04 or Ubuntu 22.04 installed on some bare-metal server or public cloud VM instance.

3 Likes
9

Hi @JxBrian! Happy to provide some context.

As part of the key rotation feature we started attaching timestamps to public keys generated by the nodes. E.g. in threshold ECDSA, the registry uses a timestamp to keep track of the registration of a key. This is used by the registry to check if it is time for nodes to rotate their keys. Recently we also allowed nodes to record locally when they generated their keys, this could be used, e.g., to raise an alert in case they are not able to register a key for a prolonged period of time.

Regarding the MR. Node keys are stored in the Crypto Service Provider (CSP), and specifically in the CSP Vault which runs in a dedicated process and performs all operations with secret keys. Since keys are only accessible within the vault, this MR introduces an API to let the rest of the replica (specifically the part of the crypto component running in the replica process) to access the key generation timestamp of some public keys. This could be then used to report some metrics about the age of the node keys.

I hope this helps understanding the MR!

5 Likes
10

@Samer, @wpb, we’ve recently switched to using podman instead of docker so our build scripts have changed a bit. If you look this README, you can see that now IC-OS image is build with ./gitlab-ci/container/build-ic -i. My colleague tested this on Windows in WSL2 and it worked. Unfortunately, this is not helpful for this proposal, it will be with the next one (changes are available from revision 08244b2bc9bbb19d417d37f6912acfebbdbf4f49 on, which is from last Friday). I’d like to emphsise again that we’re testing our build scripts on daily cadence only on Ubuntu 20.04/22.04 OS machines.

4 Likes