Jim [ARCHIVE] on Nostr: 📅 Original date posted:2013-08-05 📝 Original message:One approach you could use ...
📅 Original date posted:2013-08-05
📝 Original message:One approach you could use would be to use bitcoin signing on
a list of the build artifacts together with their SHA256 hashes.
If you have a look at the MultiBit release notes you get the
overall idea:
https://multibit.org/releases/multibit-0.5.13/release.txt
Currently these aren't machine readable but you can imagine
having a machine readable statement with:
+ a list of the files in the build
+ their SHA256 hashes
+ the above bitcoin signed by multiple signatures e.g. 2 of 3
The client can then download the file, check the signature,
check the hashes and knows which files to download.
The acceptable Bitcoin addresses for signatures would
be a whitelist in the client code.
On Mon, Aug 5, 2013, at 05:47 PM, Alan Reiner wrote:
> Indeed. You can hardcode a "distributor" public key in the software,
> and client software will only trust signed data from that key. Of
> course, the private key for that data is not kept on the server
> distributing the signed checksums. Ideally it would be kept offline,
> and the couple-times-per-year that you actually execute an upgrade, you
> sign the new checksums offline and upload the signed checksum to the
> distribution server. Then even if the server is compromised, the
> client-side software will not accept a bogus checksum because it won't
> bear the right signature.
>
> If you do this, it would be good to also have some kind of revocation
> process that can be used in the event of the offline key being
> compromised. You won't be able to "switch" keys, as that would defeat
> the purpose (the attacker who compromises the offline key could just
> issue a replacement with his own). Instead, it would be an irreversible
> broadcast that would force clients to start rejecting updates from that
> key. If the key is compromised (and find out), you broadcast the
> revocation and the users will stop auto-updating, and be given a warning
> that they should manually upgrade the software through trusted
> channels. It's not failproof, but it's a decent way to minimize damage
> if you discover compromise early enough.
>
> -Alan
>
>
>
>
>
>
> On 08/05/2013 11:54 AM, Daniel F wrote:
> > If you want package authentication, you should at least throw in some
> > digital signing, not just a checksum. With a compromised host, both the
> > checksum and binaries can be changed undetectably, but if there's a
> > signature made by a key that is not kept on the host, there's no way to
> > fake a valid binary.
> >
> > There may be other issues people would want to bring up, but surely just
> > a checksum is not sufficient.
> >
> > on 08/05/2013 10:39 AM Wendell said the following:
> >> For usability purposes, we at Hive would like to have an
> >> auto-updater
> > in our wallet app.
> >> What is a safe way to do this? I understand that Bitcoin-QT lacks
> >> such
> > an updater for security reasons... Has been thought out in more detail
> > since that decision was made?
> >> We have been toying around with the idea of placing one server
> >> behind
> > a Tor hidden service, whose only function is to output a checksum of the
> > update package. The theory is that if it is well-secured, it will at
> > least be immune to tampering at the physical hosting level.
> >> Any thoughts or advice about any of this?
> >> -wendell
> >>
> >> grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
> >>
> >>
> >>
> >> ------------------------------------------------------------------------------
> >> Get your SQL database under version control now!
> >> Version control is standard for application code, but databases havent
> >> caught up. So what steps can you take to put your SQL databases under
> >> version control? Why should you start doing it? Read more to find out.
> >> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> >>
> >>
> >>
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>
> >
> > ------------------------------------------------------------------------------
> > Get your SQL database under version control now!
> > Version control is standard for application code, but databases havent
> > caught up. So what steps can you take to put your SQL databases under
> > version control? Why should you start doing it? Read more to find out.
> > http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
https://multibit.org Money, reinvented
📝 Original message:One approach you could use would be to use bitcoin signing on
a list of the build artifacts together with their SHA256 hashes.
If you have a look at the MultiBit release notes you get the
overall idea:
https://multibit.org/releases/multibit-0.5.13/release.txt
Currently these aren't machine readable but you can imagine
having a machine readable statement with:
+ a list of the files in the build
+ their SHA256 hashes
+ the above bitcoin signed by multiple signatures e.g. 2 of 3
The client can then download the file, check the signature,
check the hashes and knows which files to download.
The acceptable Bitcoin addresses for signatures would
be a whitelist in the client code.
On Mon, Aug 5, 2013, at 05:47 PM, Alan Reiner wrote:
> Indeed. You can hardcode a "distributor" public key in the software,
> and client software will only trust signed data from that key. Of
> course, the private key for that data is not kept on the server
> distributing the signed checksums. Ideally it would be kept offline,
> and the couple-times-per-year that you actually execute an upgrade, you
> sign the new checksums offline and upload the signed checksum to the
> distribution server. Then even if the server is compromised, the
> client-side software will not accept a bogus checksum because it won't
> bear the right signature.
>
> If you do this, it would be good to also have some kind of revocation
> process that can be used in the event of the offline key being
> compromised. You won't be able to "switch" keys, as that would defeat
> the purpose (the attacker who compromises the offline key could just
> issue a replacement with his own). Instead, it would be an irreversible
> broadcast that would force clients to start rejecting updates from that
> key. If the key is compromised (and find out), you broadcast the
> revocation and the users will stop auto-updating, and be given a warning
> that they should manually upgrade the software through trusted
> channels. It's not failproof, but it's a decent way to minimize damage
> if you discover compromise early enough.
>
> -Alan
>
>
>
>
>
>
> On 08/05/2013 11:54 AM, Daniel F wrote:
> > If you want package authentication, you should at least throw in some
> > digital signing, not just a checksum. With a compromised host, both the
> > checksum and binaries can be changed undetectably, but if there's a
> > signature made by a key that is not kept on the host, there's no way to
> > fake a valid binary.
> >
> > There may be other issues people would want to bring up, but surely just
> > a checksum is not sufficient.
> >
> > on 08/05/2013 10:39 AM Wendell said the following:
> >> For usability purposes, we at Hive would like to have an
> >> auto-updater
> > in our wallet app.
> >> What is a safe way to do this? I understand that Bitcoin-QT lacks
> >> such
> > an updater for security reasons... Has been thought out in more detail
> > since that decision was made?
> >> We have been toying around with the idea of placing one server
> >> behind
> > a Tor hidden service, whose only function is to output a checksum of the
> > update package. The theory is that if it is well-secured, it will at
> > least be immune to tampering at the physical hosting level.
> >> Any thoughts or advice about any of this?
> >> -wendell
> >>
> >> grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
> >>
> >>
> >>
> >> ------------------------------------------------------------------------------
> >> Get your SQL database under version control now!
> >> Version control is standard for application code, but databases havent
> >> caught up. So what steps can you take to put your SQL databases under
> >> version control? Why should you start doing it? Read more to find out.
> >> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> >>
> >>
> >>
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>
> >
> > ------------------------------------------------------------------------------
> > Get your SQL database under version control now!
> > Version control is standard for application code, but databases havent
> > caught up. So what steps can you take to put your SQL databases under
> > version control? Why should you start doing it? Read more to find out.
> > http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
https://multibit.org Money, reinvented