6 ms·

This seems like the job for an independent non-profit organization. We need a trusted third party to rubber-stamp software signing until particular packages are

This seems like the job for an independent non-profit organization. We need a trusted third party to rubber-stamp software signing until particular packages are flagged for malicious or incompetent behavior. It shouldn't be Microsoft or Canonical.

jiggy2011 14y ago
I was thinking about this. It appears that software development is headed to become a regulated profession but the regulators will be the hardware manufacturers and platform providers. There might be value in having a recognized "professional body" where membership can be revoked but having a rubber stamp issued by such an org allows the developers code to bypass a lot of the BS. So "thou shalt not write malware" as opposed to "thou shalt not harm the interests of the platform vendor".
- WiseWeasel 14y ago
  That's likely a glimpse of our future, since it's been tried so many times in the past, but I wish we could implement something a little more automated, decentralized and less prone to human failures than a single professional ruling body with permanent expulsion for "delinquents". Maybe Github could offer a service to sign your software, free for open source, and pay for closed. They might run some kind of automated testing on your source for deviant behavior and to ensure quality, sign it, and revoke its keys if verified complaints are submitted. If the author is found to have malicious intent, then Github could ban him/revoke all his keys, and maybe a competitor could choose to sign his software instead, possibly one specializing in high-risk customers.
zokier 14y ago
mjg59 touched that on his writeup: >That's expensive. Like millions of dollars expensive. It would also take a lot of time to set up, and that's not really time we had. And, finally, nobody was jumping at the opportunity to volunteer. So no generic Linux key. http://mjg59.dreamwidth.org/12368.html http://mjg59.dreamwidth.org/12368.html
TallGuyShort 14y ago
I think the real solution is the ability for users to edit keys or disable it entirely. An independent non-profit organization still doesn't solve the problem of installing my operating system on my hardware. What if I disagree with policies of the non-profit. Until then, my solution will be to not buy such hardware at all.
- zokier 14y ago
  Secure Boot on non-ARM Windows machines will be disableable. UEFI standard has provisions for users to install their own keys too, but I haven't heard if anyone plans to implement that feature. Major problem with UEFI signing scheme is that your computer will most likely be unusable without MS keys as the firmware drivers iirc are most likely signed with MS keys.
  - TallGuyShort 14y ago
    ARM Windows machines are required to not be disableable. Non-ARM Windows machines MAY be disablable - but that's up to the manufacturer. What I'm saying is that the real solution is to require the ability for users to easily edit the configuration. It's a bit like saying the real solution isn't to defeat SOPA, but to actually pass it's opposite into law.
    - zokier 14y ago
      Windows Hardware Requirements require Secure Boot to be disableable on non-ARM platforms.

jiggy2011 14y ago

I was thinking about this. It appears that software development is headed to become a regulated profession but the regulators will be the hardware manufacturers and platform providers. There might be value in having a recognized "professional body" where membership can be revoked but having a rubber stamp issued by such an org allows the developers code to bypass a lot of the BS. So "thou shalt not write malware" as opposed to "thou shalt not harm the interests of the platform vendor".

WiseWeasel 14y ago
That's likely a glimpse of our future, since it's been tried so many times in the past, but I wish we could implement something a little more automated, decentralized and less prone to human failures than a single professional ruling body with permanent expulsion for "delinquents". Maybe Github could offer a service to sign your software, free for open source, and pay for closed. They might run some kind of automated testing on your source for deviant behavior and to ensure quality, sign it, and revoke its keys if verified complaints are submitted. If the author is found to have malicious intent, then Github could ban him/revoke all his keys, and maybe a competitor could choose to sign his software instead, possibly one specializing in high-risk customers.

zokier 14y ago

mjg59 touched that on his writeup: >That's expensive. Like millions of dollars expensive. It would also take a lot of time to set up, and that's not really time we had. And, finally, nobody was jumping at the opportunity to volunteer. So no generic Linux key. http://mjg59.dreamwidth.org/12368.html http://mjg59.dreamwidth.org/12368.html

TallGuyShort 14y ago

I think the real solution is the ability for users to edit keys or disable it entirely. An independent non-profit organization still doesn't solve the problem of installing my operating system on my hardware. What if I disagree with policies of the non-profit. Until then, my solution will be to not buy such hardware at all.

zokier 14y ago
Secure Boot on non-ARM Windows machines will be disableable. UEFI standard has provisions for users to install their own keys too, but I haven't heard if anyone plans to implement that feature. Major problem with UEFI signing scheme is that your computer will most likely be unusable without MS keys as the firmware drivers iirc are most likely signed with MS keys.
- TallGuyShort 14y ago
  ARM Windows machines are required to not be disableable. Non-ARM Windows machines MAY be disablable - but that's up to the manufacturer. What I'm saying is that the real solution is to require the ability for users to easily edit the configuration. It's a bit like saying the real solution isn't to defeat SOPA, but to actually pass it's opposite into law.
  - zokier 14y ago
    Windows Hardware Requirements require Secure Boot to be disableable on non-ARM platforms.