<blockquote>
<blockquote>
<p>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)).</p>
</blockquote>
<p>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.</p>
</blockquote>
<p>Although I think <a class="user-mention" data-hovercard-type="user" data-hovercard-url="/hovercards?user_id=241401" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/cladmi">@cladmi</a> 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.</p>
<blockquote>
<blockquote>
<p>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.</p>
</blockquote>
<p>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.</p>
</blockquote>
<p>I agree witch <a class="user-mention" data-hovercard-type="user" data-hovercard-url="/hovercards?user_id=241401" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/cladmi">@cladmi</a> concern here, even if I'm testing I do not think my personal private keys should be sent.</p>
<p>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? <code>make tests-murdock</code> sets <code>RIOT_CI_BUILD</code>, <code>SUIT_KEY_DIR</code> is forced to <code>$(BINDIR)</code>, a temporary just for testing pair of keys is generated, the <code>$(FLASH_FILE)</code> would be recompiled before sending and everything in murdock would run with this temporary pair of keys?</p>
<blockquote>
<p>So far so good. For a regular CI build, the keys from BINDIR are sent along with the test job.<br>
But if now a local user tries "make test-murdock", with the keys residing outside of BINDIR, it fails because of that.</p>
</blockquote>
<p>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?</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/RIOT-OS/RIOT/pull/11697?email_source=notifications&email_token=ABE7WYGNOWL2GDKSN6VEJZ3P7A2PDA5CNFSM4HYGWAMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZZAPVA#issuecomment-510789588">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ABE7WYFFZDU26CDRO7H4KK3P7A2PDANCNFSM4HYGWAMA">mute the thread</a>.<img src="https://github.com/notifications/beacon/ABE7WYAYS4KUMCLZBQVU2J3P7A2PDA5CNFSM4HYGWAMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZZAPVA.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/RIOT-OS/RIOT/pull/11697?email_source=notifications\u0026email_token=ABE7WYGNOWL2GDKSN6VEJZ3P7A2PDA5CNFSM4HYGWAMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZZAPVA#issuecomment-510789588",
"url": "https://github.com/RIOT-OS/RIOT/pull/11697?email_source=notifications\u0026email_token=ABE7WYGNOWL2GDKSN6VEJZ3P7A2PDA5CNFSM4HYGWAMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZZAPVA#issuecomment-510789588",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>