On Sat 2019-03-02 11:31:44 +0100, Olliver Schinagl wrote:
> Well the actualy firmware image validation will be done via a script
> there, so no worries on that regard. But if an engineer is tasked with
> modifying any of these scripts, they may struggle to know what's going
> on when invoking the t
On 01-03-2019 07:45, Daniel Kahn Gillmor wrote:
> On Wed 2019-02-27 21:10:36 +0100, Olliver Schinagl wrote:
>> During development, engineers also login to the system and may
>> need to use the gpgv tool to check things. Having to point to the exact
>> file is just common cause of imstakes 'where wa
On Wed 2019-02-27 21:10:36 +0100, Olliver Schinagl wrote:
> During development, engineers also login to the system and may
> need to use the gpgv tool to check things. Having to point to the exact
> file is just common cause of imstakes 'where was that file again' or 'oh
> forgot'. But sure it is m
Hey Daniel,
On 26-02-2019 07:45, Daniel Kahn Gillmor wrote:
> On Mon 2019-02-25 07:54:33 +0100, Olliver Schinagl wrote:
>> What I am trying to accomplish, is to generate an OS image, which
>> contains a public gpg key. The public is added using gpg --import and
>> kets added to the newly created
On Mon 2019-02-25 07:54:33 +0100, Olliver Schinagl wrote:
> What I am trying to accomplish, is to generate an OS image, which
> contains a public gpg key. The public is added using gpg --import and
> kets added to the newly created pubkey.gpg.
I think your description here is missing some backgr
While working on a little project, I found that there seems to be some
discrepancy on how gpg and gpgv are to be used.
What I am trying to accomplish, is to generate an OS image, which
contains a public gpg key. The public is added using gpg --import and
kets added to the newly created pubkey.
