Hi all,
I'm about to embark on a coreboot build+flash per Mike Banon's G505s page, but before building I want to verify signatures for the source. These appear in only one place, on the coreboot.org Downloads page, and are signed with the key:
D861AB74FB933260193399696B249D77269C04E1
The only problem is there is apparently no mention of the signing key anywhere else on the coreboot website. I usually look for some explicit, official reference (preferably in multiple contexts) to a person or org's key ID before downloading it from a keyserver. Taking the key ID from an object signature doesn't satisfy that requirement.
On 5/14/19 2:34 PM, Chris Laprise wrote:
Hi all,
I'm about to embark on a coreboot build+flash per Mike Banon's G505s page, but before building I want to verify signatures for the source. These appear in only one place, on the coreboot.org Downloads page, and are signed with the key:
D861AB74FB933260193399696B249D77269C04E1
The only problem is there is apparently no mention of the signing key anywhere else on the coreboot website. I usually look for some explicit, official reference (preferably in multiple contexts) to a person or org's key ID before downloading it from a keyserver. Taking the key ID from an object signature doesn't satisfy that requirement.
There are also several (apparently out-of-tree) patches referenced on the G505s howto:
http://dangerousprototypes.com/docs/Lenovo_G505S_hacking
I'll have to get signatures or similar type of verification for these as well. Any help in this regard would be appreciated.
On 5/14/19 Chris Laprise wrote:
There are also several (apparently out-of-tree) patches referenced on the G505s howto:
http://dangerousprototypes.com/docs/Lenovo_G505S_hacking
I'll have to get signatures or similar type of verification for these as well. Any help in this regard would be appreciated.
I can understand the value in having releases signed as they are somewhat officially attached to a project. But for random patches your best bet will be to analyze their content, not their origin.
Patrick
On 5/14/19 3:17 PM, Patrick Georgi via coreboot wrote:
On 5/14/19 Chris Laprise wrote:
There are also several (apparently out-of-tree) patches referenced on the G505s howto:
http://dangerousprototypes.com/docs/Lenovo_G505S_hacking
I'll have to get signatures or similar type of verification for these as well. Any help in this regard would be appreciated.
I can understand the value in having releases signed as they are somewhat officially attached to a project. But for random patches your best bet will be to analyze their content, not their origin.
I might put firmware code analysis on my bucket list for the next life, if I convert to Buddhism. :)
When I look at review.coreboot.org and the patches have logged commits (ostensibly, these are at least hashed) and I see "Patrick Georgi" as reviewer... there is no assurance of fidelity from those records?
Chris Laprise:
I might put firmware code analysis on my bucket list for the next life, if I convert to Buddhism. :)
FWIW, those AMD CPU microcode updates are encrypted, so you should also include cryptanalysis on your bucket list. Don't believe the video ones are, though.
On 5/14/19 3:57 PM, awokd via coreboot wrote:
Chris Laprise:
I might put firmware code analysis on my bucket list for the next life, if I convert to Buddhism. :)
FWIW, those AMD CPU microcode updates are encrypted, so you should also include cryptanalysis on your bucket list. Don't believe the video ones are, though.
To be fair, I think Patrick meant "compare" the patch with what AMD distributed. If they are the same verbatim – and the authors (AMD etc) have a verification method – then that may be do-able.
On Tue, May 14, 2019 at 03:50:18PM -0400, Chris Laprise wrote:
When I look at review.coreboot.org and the patches have logged commits (ostensibly, these are at least hashed) and I see "Patrick Georgi" as reviewer... there is no assurance of fidelity from those records?
So what is it you're missing that you require signatures for patches?
FWIW Gerrit (the software driving review.coreboot.org) supported signed pushes, but I don't think many people are aware of that or use the feature.
It's also of somewhat limited use as Gerrit cherry-picks into master which loses the signature again.
Patrick
Hi Chris, if you'd like to verify the microcodes inside my AMD ucode patch: convert the hexadecimal arrays at their .c files back to binary, extract the microcodes from proprietary UEFI updates for those few AMD boards that are still getting them ( or get them already extracted by platomav from platomav's CPUMicrocodes repository - https://github.com/platomav/CPUMicrocodes ), and compare. They will match 1:1. And if you have any questions about any other parts of my patches, I'll try my best to address them.
On Wed, May 15, 2019 at 12:41 AM Patrick Georgi via coreboot coreboot@coreboot.org wrote:
On Tue, May 14, 2019 at 03:50:18PM -0400, Chris Laprise wrote:
When I look at review.coreboot.org and the patches have logged commits (ostensibly, these are at least hashed) and I see "Patrick Georgi" as reviewer... there is no assurance of fidelity from those records?
So what is it you're missing that you require signatures for patches?
FWIW Gerrit (the software driving review.coreboot.org) supported signed pushes, but I don't think many people are aware of that or use the feature.
It's also of somewhat limited use as Gerrit cherry-picks into master which loses the signature again.
Patrick
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
On 5/16/19 2:35 PM, Mike Banon wrote:
Hi Chris, if you'd like to verify the microcodes inside my AMD ucode patch: convert the hexadecimal arrays at their .c files back to binary, extract the microcodes from proprietary UEFI updates for those few AMD boards that are still getting them ( or get them already extracted by platomav from platomav's CPUMicrocodes repository - https://github.com/platomav/CPUMicrocodes ), and compare. They will match 1:1. And if you have any questions about any other parts of my patches, I'll try my best to address them.
Thanks. I'm a neophyte when it comes to firmware, and I'm just now inferring that there is no way for me to compare AMD patches directly since it appears AMD doesn't publish them.
I'm willing to accept the patches if they are harvested, reviewed and then signed by the coreboot project. But I don't know when or if they will be merged and available this way in the upcoming 4.10 release.
I also don't know which patches are considered necessary and which are listed because they are nice to have.
For reference, I intend to run Qubes OS, so I don't need discrete graphics, but it appears I'll need AtomBIOS. Will AtomBIOS be merged with the upcoming 4.10 release? I can't tell. Going down the list, "tint" is indicated but there is no What or Why or a link, and I can't turn up any background info by searching. OTOH, it looks like I can skip the SeaBIOS patch.
there is no way for me to compare AMD patches directly since it appears AMD doesn't publish them
There is a way: a bit later I will privately share a small list of AMD boards that are still getting the UEFI updates (to help you to obtain these microcodes by yourself), and will also share a small C program that converts a hexadecimal arrays provided by my patches (could be copy-pasted) back to a binary. After you'll successfully get both of these, you could SHA256 compare them between each other by yourself - to see that they are indeed 1:1 matching.
I'm willing to accept the patches if they are harvested, reviewed and then signed by the coreboot project
Both the new AMD microcodes and AtomBIOS binaries haven't been released officially yet and waiting for the official release by AMD to get them merged to coreboot master. They can't be merged until the official release. Currently we are in the talks with AMD, but these matters are advancing slowly - so the people who don't want to wait and need them now, could be using them locally and unofficially. Some of these patches are almost 1 year old already, I guess this is enough time for the concerned people from a coreboot community to quickly look through theses patches to at least see that there is nothing harmful. Also you could see that I'm a coreboot community member for > 3 years and of course not going to ruin my hard earned reputation by intentionally submitting something harmful :P So, if you trust - you can use these patches, but if don't trust - can wait, perhaps a lot... And I don't think any extra signature is necessary, also because these tiny scripts which are downloading/extracting the patches - also check their SHA256.
I don't know when or if they will be merged
We don't know too, Chris, it all depends on AMD...
I don't know which patches are considered necessary and which are listed because they are nice to have.
Perhaps all of these patches could be considered as optional, since the people somehow built and used coreboot on their G505S before these patches even existed. However, you told that you are going to use a QubesOS which relies on good function of low level virtualization, that means a new AMD microcode is required for you - otherwise you'll run into the freezing problems.
Looking through a list of patches at our DangerousPrototypes "Lenovo G505S hacking" page:
1) AMD microcode updates - required for you, could get by yourself to check
2) Discrete GPU support - optional, and you can verify these 10+67+20 = 97 lines of source code by yourself
3) AMD GPU AtomBIOS blobs - perhaps the AtomBIOS blob for integrated GPU is required for you - because it seems you don't want to run G505S in a headless mode - but you could easily get it by yourself ; also could for a discrete GPU, however it is significantly more difficult and time consuming
4) tint build system - optional, however it adds the important checksum verification for a tint archive that is downloaded from FSF server. Sorry that I forgot to write a readme at DP wiki for this one, still it is available at my tint patch commit message. And "tint" is a small opensource tetris game that will be available at your SeaBIOS boot menu, to have a lot of fun and maybe to show off to your friends what your new awesome BIOS can do ;-)
5) Unofficial SeaBIOS patches - optional because it seems you are not going to have more than 10 menu entries, however your mind could change if you'd also become interested at these floppy-based operating systems. Mostly for fun (e.g. MichalOS has a cool built-in piano), but some of their features could be useful to your for the real purposes: e.g. as soon as the KolibriOS networking driver will be completed for the network controller of our G505S, it will be possible to access the Internet and chat with your friends using IRCC. And it seems that all these listed floppy-based OS, with the exception of a plop bootloader floppy, are 100% open source which already gives some trust to them
6) Sample G505S .config - optional, since you could configure by yourself, but of course this config is 100% open source and you could look through it to verify that there are no harmful options enabled, and I'm using such a config by myself without any problems.
Best regards, Mike Banon
On Mon, May 20, 2019 at 4:32 AM Chris Laprise tasket@posteo.net wrote:
On 5/16/19 2:35 PM, Mike Banon wrote:
Hi Chris, if you'd like to verify the microcodes inside my AMD ucode patch: convert the hexadecimal arrays at their .c files back to binary, extract the microcodes from proprietary UEFI updates for those few AMD boards that are still getting them ( or get them already extracted by platomav from platomav's CPUMicrocodes repository - https://github.com/platomav/CPUMicrocodes ), and compare. They will match 1:1. And if you have any questions about any other parts of my patches, I'll try my best to address them.
Thanks. I'm a neophyte when it comes to firmware, and I'm just now inferring that there is no way for me to compare AMD patches directly since it appears AMD doesn't publish them.
I'm willing to accept the patches if they are harvested, reviewed and then signed by the coreboot project. But I don't know when or if they will be merged and available this way in the upcoming 4.10 release.
I also don't know which patches are considered necessary and which are listed because they are nice to have.
For reference, I intend to run Qubes OS, so I don't need discrete graphics, but it appears I'll need AtomBIOS. Will AtomBIOS be merged with the upcoming 4.10 release? I can't tell. Going down the list, "tint" is indicated but there is no What or Why or a link, and I can't turn up any background info by searching. OTOH, it looks like I can skip the SeaBIOS patch.
--
Chris Laprise, tasket@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
Huge Thanks to Martin Roth, finally we got a permission from AMD to merge the new microcode patches - and Martin has just merged them ! ;-) So the things became slightly easier and luckily now you could disregard some microcode-related parts of my last message. And we need to walk the same path for the AtomBIOS ROMs - should be successful there as well, although perhaps would take another year or so :P
Best regards, Mike Banon
On Mon, May 20, 2019 at 6:43 PM Mike Banon mikebdp2@gmail.com wrote:
there is no way for me to compare AMD patches directly since it appears AMD doesn't publish them
There is a way: a bit later I will privately share a small list of AMD boards that are still getting the UEFI updates (to help you to obtain these microcodes by yourself), and will also share a small C program that converts a hexadecimal arrays provided by my patches (could be copy-pasted) back to a binary. After you'll successfully get both of these, you could SHA256 compare them between each other by yourself - to see that they are indeed 1:1 matching.
I'm willing to accept the patches if they are harvested, reviewed and then signed by the coreboot project
Both the new AMD microcodes and AtomBIOS binaries haven't been released officially yet and waiting for the official release by AMD to get them merged to coreboot master. They can't be merged until the official release. Currently we are in the talks with AMD, but these matters are advancing slowly - so the people who don't want to wait and need them now, could be using them locally and unofficially. Some of these patches are almost 1 year old already, I guess this is enough time for the concerned people from a coreboot community to quickly look through theses patches to at least see that there is nothing harmful. Also you could see that I'm a coreboot community member for > 3 years and of course not going to ruin my hard earned reputation by intentionally submitting something harmful :P So, if you trust - you can use these patches, but if don't trust - can wait, perhaps a lot... And I don't think any extra signature is necessary, also because these tiny scripts which are downloading/extracting the patches - also check their SHA256.
I don't know when or if they will be merged
We don't know too, Chris, it all depends on AMD...
I don't know which patches are considered necessary and which are listed because they are nice to have.
Perhaps all of these patches could be considered as optional, since the people somehow built and used coreboot on their G505S before these patches even existed. However, you told that you are going to use a QubesOS which relies on good function of low level virtualization, that means a new AMD microcode is required for you - otherwise you'll run into the freezing problems.
Looking through a list of patches at our DangerousPrototypes "Lenovo G505S hacking" page:
AMD microcode updates - required for you, could get by yourself to check
Discrete GPU support - optional, and you can verify these 10+67+20
= 97 lines of source code by yourself
- AMD GPU AtomBIOS blobs - perhaps the AtomBIOS blob for integrated
GPU is required for you - because it seems you don't want to run G505S in a headless mode - but you could easily get it by yourself ; also could for a discrete GPU, however it is significantly more difficult and time consuming
- tint build system - optional, however it adds the important
checksum verification for a tint archive that is downloaded from FSF server. Sorry that I forgot to write a readme at DP wiki for this one, still it is available at my tint patch commit message. And "tint" is a small opensource tetris game that will be available at your SeaBIOS boot menu, to have a lot of fun and maybe to show off to your friends what your new awesome BIOS can do ;-)
- Unofficial SeaBIOS patches - optional because it seems you are not
going to have more than 10 menu entries, however your mind could change if you'd also become interested at these floppy-based operating systems. Mostly for fun (e.g. MichalOS has a cool built-in piano), but some of their features could be useful to your for the real purposes: e.g. as soon as the KolibriOS networking driver will be completed for the network controller of our G505S, it will be possible to access the Internet and chat with your friends using IRCC. And it seems that all these listed floppy-based OS, with the exception of a plop bootloader floppy, are 100% open source which already gives some trust to them
- Sample G505S .config - optional, since you could configure by
yourself, but of course this config is 100% open source and you could look through it to verify that there are no harmful options enabled, and I'm using such a config by myself without any problems.
Best regards, Mike Banon
On Mon, May 20, 2019 at 4:32 AM Chris Laprise tasket@posteo.net wrote:
On 5/16/19 2:35 PM, Mike Banon wrote:
Hi Chris, if you'd like to verify the microcodes inside my AMD ucode patch: convert the hexadecimal arrays at their .c files back to binary, extract the microcodes from proprietary UEFI updates for those few AMD boards that are still getting them ( or get them already extracted by platomav from platomav's CPUMicrocodes repository - https://github.com/platomav/CPUMicrocodes ), and compare. They will match 1:1. And if you have any questions about any other parts of my patches, I'll try my best to address them.
Thanks. I'm a neophyte when it comes to firmware, and I'm just now inferring that there is no way for me to compare AMD patches directly since it appears AMD doesn't publish them.
I'm willing to accept the patches if they are harvested, reviewed and then signed by the coreboot project. But I don't know when or if they will be merged and available this way in the upcoming 4.10 release.
I also don't know which patches are considered necessary and which are listed because they are nice to have.
For reference, I intend to run Qubes OS, so I don't need discrete graphics, but it appears I'll need AtomBIOS. Will AtomBIOS be merged with the upcoming 4.10 release? I can't tell. Going down the list, "tint" is indicated but there is no What or Why or a link, and I can't turn up any background info by searching. OTOH, it looks like I can skip the SeaBIOS patch.
--
Chris Laprise, tasket@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
Mike Banon:
Huge Thanks to Martin Roth, finally we got a permission from AMD to merge the new microcode patches - and Martin has just merged them ! ;-) So the things became slightly easier and luckily now you could disregard some microcode-related parts of my last message. And we need to walk the same path for the AtomBIOS ROMs - should be successful there as well, although perhaps would take another year or so :P
Thank you Martin, Mike and AMD!
On 5/20/19 12:02 PM, Mike Banon wrote:
Huge Thanks to Martin Roth, finally we got a permission from AMD to merge the new microcode patches - and Martin has just merged them ! ;-) So the things became slightly easier and luckily now you could disregard some microcode-related parts of my last message. And we need to walk the same path for the AtomBIOS ROMs - should be successful there as well, although perhaps would take another year or so :P
That is good news about the patches. However, it will require the inclusion of AtomBIOS to be usable in most cases, including my own.
Thanks for going over the patch+blob options. It does appear we are now stuck on just the AtomBIOS verification, assuming the AMD microcode patches make it into coreboot 4.10. Unfortunately, system firmware is now being targeted via remote attacks and I'm not sure how many different AMD APU systems I'd have to scan to be reasonably sure I don't have an exploited copy. If I use a copy from gerrit or github, then I'm relying strictly on https security; this is true whether or not hashes are posted since they are not good assurance unless they are signed.
If there is any appeal you can make to AMD about AtomBIOS, I think it could be of great benefit for anyone looking to AMD and coreboot as more secure alternatives (and not just for older CPUs).
What's good about the AtomBIOS ROMs: you can use AtomDis tool ( [1] / [2] ) to get some idea - about what's inside them and what they're doing. Run "make" to compile it and then use a command like ./atomdis pci1002,990b.rom F > pci1002,990b.rom.dis . I'm sharing my disassemblies as .dis files at [3] repository and you're welcome to take a look at them.
Although I don't think they could do anything malicious, as an additional security measure you could consider the YABEL options explained at the end of this message. E.g. " [to prevent] the Option ROMs from doing dirty tricks with the CPU (such as installing SMM modules or hypervisors) " . Personally I have the following combination inside my .config shared at [4] , and haven't experienced any GPU problems from them. Maybe a slightly stricter set of these options would work perfectly as well, I haven't checked.
PCI_OPTION_ROM_RUN_YABEL [=y] Secure mode YABEL_DIRECTHW [=y] Direct hardware access YABEL_PCI_ACCESS_OTHER_DEVICES [=y] Allow Option ROMs to access other devices YABEL_PCI_FAKE_WRITING_OTHER_DEVICES_CONFIG [=n] Fake success on writing other device's config space YABEL_VIRTMEM_LOCATION [=0x1000000] ( that was a default address, unchanged )
If you don't want to rely on someone else's AtomBIOS ROMs, you could extract them by yourself while a proprietary UEFI is still flashed. 1) to get the integrated GPU AtomBIOS ROM, can use the "Retrieval via Linux kernel" method: [5] 2) to get the discrete GPU AtomBIOS ROM, use (a bit time consuming!) instructions provided here: [6]
Then you'll be able to compare them with what I have submitted. Extra check is always good, e.g. because Matt's self-extracted AtomBIOS ROM for iGPU turned out a bit different because of some minor hardware differences (perhaps a slightly different LCD panel) - read a discussion [7] . Soon I'm going to test his iGPU ROM version on my PC, as well as maybe he would test my ROM version at his, to make sure they are crosscompatible and that I don't have to provide the multiple iGPU ROM versions inside my [8] patch.
[1] - https://cgit.freedesktop.org/~mhopf/AtomDis/ [2] - https://github.com/mikebdp2/AtomDis [3] - https://github.com/mikebdp2/atombioses [4] - https://review.coreboot.org/c/coreboot/+/32352 [5] - https://www.coreboot.org/VGA_support#Retrieval_via_Linux_kernel [6] - https://mail.coreboot.org/pipermail/coreboot/2017-July/084660.html [7] - https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/LKB4V... [8] - https://review.coreboot.org/c/coreboot/+/31944
=> YABEL configuration options: ( use / key at make menuconfig menu to find out their menu path )
CONFIG_PCI_OPTION_ROM_RUN_YABEL: If you select this option, the x86emu CPU emulator will be used to execute PCI Option ROMs. This option prevents Option ROMs from doing dirty tricks with the system (such as installing SMM modules or hypervisors), but it is also significantly slower than the native Option ROM initialization method.
CONFIG_YABEL_PCI_ACCESS_OTHER_DEVICES: Per default, YABEL only allows Option ROMs to access the PCI device that they are associated with. However, this causes trouble for some onboard graphics chips whose Option ROM needs to reconfigure the north bridge.
CONFIG_YABEL_PCI_FAKE_WRITING_OTHER_DEVICES_CONFIG: By default, YABEL aborts when the Option ROM tries to write to other devices' config spaces. With this option enabled, the write doesn't follow through, but the Option ROM is allowed to go on. This can create issues such as hanging Option ROMs (if it depends on that other register changing to the written value), so test for impact before using this option.
CONFIG_YABEL_VIRTMEM_LOCATION: YABEL requires 1MB memory for its CPU emulation. This memory is normally located at 16MB.
CONFIG_YABEL_DIRECTHW: YABEL consists of two parts: It uses x86emu for the CPU emulation and additionally provides a PC system emulation that filters bad device and memory access (such as PCI config space access to other devices than the initialized one). When choosing this option, x86emu will pass through all hardware accesses to memory and I/O devices to the underlying memory and I/O addresses. While this option prevents Option ROMs from doing dirty tricks with the CPU (such as installing SMM modules or hypervisors), they can still access all devices in the system. Enable this option for a good compromise between security and speed.
Best regards, Mike Banon
On Tue, May 21, 2019 at 10:31 PM Chris Laprise tasket@posteo.net wrote:
On 5/20/19 12:02 PM, Mike Banon wrote:
Huge Thanks to Martin Roth, finally we got a permission from AMD to merge the new microcode patches - and Martin has just merged them ! ;-) So the things became slightly easier and luckily now you could disregard some microcode-related parts of my last message. And we need to walk the same path for the AtomBIOS ROMs - should be successful there as well, although perhaps would take another year or so :P
That is good news about the patches. However, it will require the inclusion of AtomBIOS to be usable in most cases, including my own.
Thanks for going over the patch+blob options. It does appear we are now stuck on just the AtomBIOS verification, assuming the AMD microcode patches make it into coreboot 4.10. Unfortunately, system firmware is now being targeted via remote attacks and I'm not sure how many different AMD APU systems I'd have to scan to be reasonably sure I don't have an exploited copy. If I use a copy from gerrit or github, then I'm relying strictly on https security; this is true whether or not hashes are posted since they are not good assurance unless they are signed.
If there is any appeal you can make to AMD about AtomBIOS, I think it could be of great benefit for anyone looking to AMD and coreboot as more secure alternatives (and not just for older CPUs).
--
Chris Laprise, tasket@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
Hi Chris, I'll get my public key uploaded to the website shortly. Thanks for pointing out the issue. Martin
On Tue, May 14, 2019 at 12:34 PM Chris Laprise tasket@posteo.net wrote:
Hi all,
I'm about to embark on a coreboot build+flash per Mike Banon's G505s page, but before building I want to verify signatures for the source. These appear in only one place, on the coreboot.org Downloads page, and are signed with the key:
D861AB74FB933260193399696B249D77269C04E1
The only problem is there is apparently no mention of the signing key anywhere else on the coreboot website. I usually look for some explicit, official reference (preferably in multiple contexts) to a person or org's key ID before downloading it from a keyserver. Taking the key ID from an object signature doesn't satisfy that requirement.
--
Chris Laprise, tasket@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi,
These appear in only one place, on the coreboot.org Downloads page, and are signed with the key:
D861AB74FB933260193399696B249D77269C04E1
The only problem is there is apparently no mention of the signing key anywhere else on the coreboot website. I usually look for some explicit, official reference (preferably in multiple contexts) to a person or org's key ID before downloading it from a keyserver. Taking the key ID from an object signature doesn't satisfy that requirement.
For whatever it's worth: that's my key (for my non-corporate email addresses) and I'm the legit (and to my knowledge) only holder of its private key.
I guess I could add it to the site but then again that's the same server as the one you're download the archive and signature from, so if somebody manages to tamper with the archive they could also put their own key there. I'll make sure to get a few signatures onto the key so it's hooked up with the web of trust, but that won't happen very soon.
Patrick
Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
-
awokd -
Chris Laprise -
Martin Roth -
Mike Banon -
Patrick Georgi