[riot-notifications] [RIOT-OS/RIOT] murdock: allow multiple files to be sent along with a test job (#11697)
notifications at github.com
Fri Jul 12 09:57:37 CEST 2019
> > It would make more sense from a general build system point of view to have a COMPILED_BINARIES, DISTRIBUTED_FILES or another name that by default contains $(ELFFILE) $(FLASHFILE) (and currently $(HEXFILE)).
> Well, right now the use case is testing. I'm happy to rename the variable to whatever fits better. Should do that when there is another use-case.
Although I think @cladmi comment here is valid I agree with the fact that this can be added when the use case arises, no need to add it now when there is no use-case.
> > I would not support any direction where a private key needs to be sent to an external test setup. These things are normally stored in a central system place with limited permissions and a passphrase or even on external hardware to never be seen.
> This is meant for testing, the key does not need to be kept secret. Providing a secure key distribution system in order to provide a rather open test system with "secure" keys is a complete waste of time.
I agree witch @cladmi concern here, even if I'm testing I do not think my personal private keys should be sent.
But I don't see why a pair of keys can't be generated just for testing, and those be sent out to the workers? Maybe I'm not following correctly but isn't that what is happening here? `make tests-murdock` sets `RIOT_CI_BUILD`, `SUIT_KEY_DIR` is forced to `$(BINDIR)`, a temporary just for testing pair of keys is generated, the `$(FLASH_FILE)` would be recompiled before sending and everything in murdock would run with this temporary pair of keys?
> So far so good. For a regular CI build, the keys from BINDIR are sent along with the test job.
> But if now a local user tries "make test-murdock", with the keys residing outside of BINDIR, it fails because of that.
If the user insists on using his personal private keys for testing a warning message where he is informed that they are being sent in a insecure way should be enough for now, or even an error message which the user could comment out to force it. What do you think?
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the notifications