Skip to content
  1. Apr 15, 2024
    • Javyer's avatar
      added script to require a review post push (#3431) · 8b4cfda7
      Javyer authored 
      Closes https://github.com/paritytech/opstooling/issues/174

Added a new step in the action that triggers review bot to stop approval
from new pushes.

This step works in the following way:
- If the **author of the PR**, who **is not** a member of the org,
pushed a new commit then:
- Review-Trigger requests new reviews from the reviewers and fails.

It *does not dismiss reviews*. It simply request them again, but they
will still be available.

This way, if the author changed something in the code, they will still
need to have this latest change approved to stop them from uploading
malicious code.

Find the requested issue linked to this PR (it is from a private repo so
I can't link it here)
      8b4cfda7
    • Bastian Köcher's avatar
      pallet_broker: Support renewing leases expired in a previous period (#4089) · 6f73b746
      Bastian Köcher authored 
      Part of: https://github.com/paritytech/polkadot-sdk/issues/4107
      6f73b746
    • Bastian Köcher's avatar
      sp-api: Use macro to detect if `frame-metadata` is enabled (#4117) · d1b0ef76
      Bastian Köcher authored 
      While `sp-api-proc-macro` isn't used directly and thus, it should have
the same features enabled as `sp-api`. However, I have seen issues
around `frame-metadata` not being enabled for `sp-api`, but for
`sp-api-proc-macro`. This can be prevented by using the
`frame_metadata_enabled` macro from `sp-api` that ensures we have the
same feature set between both crates.
      d1b0ef76
    • Svyatoslav Nikolsky's avatar
      Bridge: slash destination may be an explicit account (#4106) · 6acf4787
      Svyatoslav Nikolsky authored 
      Extracted to a separate PR as requested here:
https://github.com/paritytech/parity-bridges-common/pull/2873#discussion_r1562459573
      6acf4787
    • Alexandru Gheorghe's avatar
      Prevent accidental change of network-key for active authorities (#3852) · 2bc4ed11
      Alexandru Gheorghe authored 
      As discovered during investigation of
https://github.com/paritytech/polkadot-sdk/issues/3314 and
https://github.com/paritytech/polkadot-sdk/issues/3673 there are active
validators which accidentally might change their network key during
restart, that's not a safe operation when you are in the active set
because of distributed nature of DHT, so the old records would still
exist in the network until they expire 36h, so unless they have a good
reason validators should avoid changing their key when they restart
their nodes.

There is an effort in parallel to improve this situation
https://github.com/paritytech/polkadot-sdk/pull/3786

, but those changes
are way more intrusive and will need more rigorous testing, additionally
they will reduce the time to less than 36h, but the propagation won't be
instant anyway, so not changing your network during restart should be
the safest way to run your node, unless you have a really good reason to
change it.

## Proposal
1. Do not auto-generate the network if the network file does not exist
in the provided path. Nodes where the key file does not exist will get
the following error:
```
Error: 
   0: Starting an authorithy without network key in /home/alexggh/.local/share/polkadot/chains/ksmcc3/network/secret_ed25519.
      
       This is not a safe operation because the old identity still lives in the dht for 36 hours.
      
       Because of it your node might suffer from not being properly connected to other nodes for validation purposes.
      
       If it is the first time running your node you could use one of the following methods.
      
       1. Pass --unsafe-force-node-key-generation and make sure you remove it for subsequent node restarts
      
       2. Separetly generate the key with: polkadot key generate-node-key --file <YOUR_PATH_TO_NODE_KEY>
```

2. Add an explicit parameters for nodes that do want to change their
network despite the warnings or if they run the node for the first time.
`--unsafe-force-node-key-generation`

3. For `polkadot key generate-node-key` add two new mutually exclusive
parameters `base_path` and `default_base_path` to help with the key
generation in the same path the polkadot main command would expect it.
 
4. Modify the installation scripts to auto-generate a key in default
path if one was not present already there, this should help with making
the executable work out of the box after an instalation.

## Notes

Nodes that do not have already the key persisted will fail to start
after this change, however I do consider that better than the current
situation where they start but they silently hide that they might not be
properly connected to their peers.

## TODO
- [x] Make sure only nodes that are authorities on producation chains
will be affected by this restrictions.
- [x] Proper PRDOC, to make sure node operators are aware this is
coming.

---------

Signed-off-by: default avatarAlexandru Gheorghe <[email protected]>
Co-authored-by: default avatarDmitry Markin <[email protected]>
Co-authored-by: default avatars0me0ne-unkn0wn <[email protected]>
Co-authored-by: default avatarBastian Köcher <[email protected]>
      2bc4ed11
  3. Apr 14, 2024
  5. Apr 13, 2024
  7. Apr 12, 2024
  9. Apr 11, 2024
  11. Apr 10, 2024