Add SHA256 signatures of the install script #8312
Conversation
Codecov ReportPatch coverage has no change and project coverage change:
Additional details and impacted files@@ Coverage Diff @@
## master #8312 +/- ##
==========================================
+ Coverage 47.61% 48.94% +1.33%
==========================================
Files 143 140 -3
Lines 14732 11817 -2915
==========================================
- Hits 7014 5784 -1230
+ Misses 6623 4921 -1702
- Partials 1095 1112 +17
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
|
I'm on the fence about this, as anyone running a Please add a test to the validate script to confirm that the checksums match the install script; to avoid accidentally updating the script without touching the checksums. |
|
@brandond Please have a look. I've added invocations to And may I ask, how can the signatures be part of the release artifacts? what should I edit to have them there too? As a side note:
I partially agree, I see the comfort for a PoC on an isolated machine to do It might be silly (and I'm not an expert in security at all) but I like the simple way composer.org offers to use their install guide:
Yes, you're downloading things from the wild internet, but you get to verify the integrity of the script with what the docs are telling you (a lot of oversimplification here, I grant that). Another side-side note, a quick scan over the repo shows: that technique (curl pipe sh) is present in:
in a Vagrantfile:
They don't seem to be a problem now, but are definitely potential attack surfaces, they should be closed in as time permits. |
That's actually the documented install method for both projects: |
They do are. That doesn't necessarily means it's a "safe" way to install, it's the same I think we're both on the same page: the problem itself is not running And what I'd like to achieve is to have that very minimum thing, a way to validate the integrity of the script that's running as the root user of a system and performing changes to the system.* Tailscale offers packaged RPM's & DEB's with GPG signatures, so at least is possible to verify the package (which is done automagically by dnf/zypper/apt/etc). And
But then below has a snippet of code Nevertheless, when following the releases page link, there's a checksums file to verify the integrity of the artifact downloaded. ^*: mistyped enter when writing the message, sorry for the noise. |
- SHA256 Signature of the install script - Added a sha256sum invocations in the validate script. These calls will validate that the install script signatures match. And when the script is changed the signatures must be recalculated as reported by the error message in sha256sum. Signed-off-by: Jose D. Gomez R <[email protected]>
josegomezr
changed the title
|
Updated the title and description to match the current state (only sha256 signatures). |
Just to close the loop on this - they will not be release artifacts. The install script is served directly off the master branch; it is not part of the built release artifacts. If someone wants to use the checksum, they'll need to pull it down from github. |
|
how can the signatures be part of the release artifacts
Just to close the loop on this - they will not be release artifacts. The install script is served directly off the master branch; it is not part of the built release artifacts. If someone wants to use the checksum, they'll need to pull it down from github.
It is still a step forward, and we can pull the checksum directly from openqa.opensuse.org or openqa.suse.de and I guess security concious users or those working in regulated industries can also refer to it.
|
Proposed Changes
Add SHA256 signatures of the install script.
Types of Changes
Verification
Testing
Linked Issues
User-Facing Change
No functional change
Further Comments
get.k3s.iotoo.