Dmitriy Matrenichev

Results 70 comments of Dmitriy Matrenichev

Closed, there should be better solution.

The thing is, under current implementation you will never see `fatal controller runtime error` because receiving from the channel happens after running from the sequencer, which, as it turns out,...

Reopening this, cause this looks interesting.

30% improvement after https://github.com/siderolabs/discovery-service/pull/60 and https://github.com/siderolabs/discovery-service/pull/61. Works continues. ![image](https://github.com/siderolabs/discovery-service/assets/6999905/06bfd378-4797-453f-b85a-4c8bc879bd3b)

Relevant test added that covers both this and #231

Both https://github.com/ProtonMail/go-crypto/blob/58e86b2947569471f4657525aeb6e835e7c7d3eb/openpgp/packet/signature.go#L604-L615 and https://github.com/ProtonMail/go-crypto/blob/58e86b2947569471f4657525aeb6e835e7c7d3eb/openpgp/packet/public_key.go#L791-L802 Make no requirements about passed and creation time having second prevision. We can use Trunc there, but is it correct way?

[openpgp.Entity.EncryptionKey](https://github.com/ProtonMail/go-crypto/blob/58e86b2947569471f4657525aeb6e835e7c7d3eb/openpgp/keys.go#L121) is public method which accepts non-truncated time. I suppose there are also other ways to pass nsec time to `KeyExpired` functions. Truncating there should safe-guard against that getting in.

@twiss https://github.com/ProtonMail/go-crypto/pull/168 like this?

Hello! Thanks for the heads up - I believe this problem comes from the fact that grpc package structure had changed once again. I will look into it as soon...