Re: [qubes-devel] Timestamp canaries

2018-03-09 Thread Innovative Inventor
On Friday, March 9, 2018 at 9:57:47 PM UTC-5, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 2018-03-09 16:12, Peter Todd wrote:
> > On Fri, Mar 09, 2018 at 12:19:47PM -0800,
> > theinnovativeinven...@gmail.com wrote:
> >> I was looking at the canaries, and I liked the idea of a proof of
> >> freshness with the latest news headlines. While people can't
> >> create canaries ahead of time, it is possible to conspire to
> >> modify or backdate one of them after they have been published. To
> >> prevent this, we could use a blockchain-based timestamp, where
> >> the hashes of each canary are placed within the blockchain of a
> >> powerful cryptocurrency. Something similar to these services:
> >> 
> >> https://opentimestamps.org/ http://originstamp.org/home
> >> 
> >> This way, if there ever is a interruption of canaries, followed
> >> by a court order or something forcing you guys to backdate a
> >> falsified canary or modify old ones, we will all be able to
> >> check.
> > 
> > The easiest way to do this is to simply use the OpenTimestamps
> > (OTS) git integration. This blog post explains how:
> > 
> > https://petertodd.org/2016/opentimestamps-git-integration
> > 
> > Addiitionally, while not covered in that blog post, OTS also
> > supports a mode where it rehashes the git tree in such a way that
> > an efficient, SHA256-based, timestamp proof can be extracted later
> > for each file. In the next release this will be done by default,
> > but for now you have to add the --rehash-trees option where the
> > ots-git-gpg-wrapper command is called.
> > 
> > FWIW, as of this week, Bitcoin Core maintainer Wladimir J. van der
> > Laan started using OTS to timestamp Bitcoin Core commits and tags.
> > 
> 
> Related issue:
> https://github.com/QubesOS/qubes-issues/issues/2847
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlqjSZoACgkQ203TvDlQ
> MDDIihAAyu8mH1+bqRR/to4nEzEsVZGP9Y2EMx0JSc2KVN3iZ/nfsoDp1h3vbLDe
> r79AZAJZVvjB6VEJCyMgqfa9ZirwT3Ri0g/9ozN9XFn3gdNt1rkz21lsW/nabtpV
> P0lLoPOOcCaLWiHHXbRBa3RrntOYp1f3ReFRg0+He9QcmD8aATm43euaPZ+Y/OMb
> jhskfSLu9jHh4Ef0R+wXYnjtN7FNwuccy+WuByTzmlT2BbLfjTljo4pahEaDqPKo
> mkX330EhVYEXmNfTiV07MmFmYtd2/9zAWB2cZCYsv7S0dh5dc3MyGzQW+pscNyMU
> JroXQOtC1JgqctQSkKVPNAiGjzrz5e+RL8K6E+xpCh8tvDNZtPbcCC5S91AsvdOj
> N9cxyFFWZiOq7FVO0Wjg0Rvamm67uLFRyLYVPCNj6KeZ6wsPspU32OqCZtXkVTNW
> BnGts+Ooo7Z8JW0vsHo/n3kcTYhMp40sBtl4dI1oKMrkoYR8LjM2H98wecdZKl9i
> kArYv8WQzgGAFn0631Z3pPRw2g9kVkssH0vrOMuDxYCLiqFg8ImIbx0AhMtPlTEA
> pGYsYrL/V2OgvjBGNFcfmtTtprY8SGUFAcIBrVZUcAH4lGntLJW8D2MSmhy+9bpy
> 8cbbhdqeqHSI5meVyaVahL+7GCx4/gggivvd81WdY0lVkZTjpCE=
> =Oc4Y
> -END PGP SIGNATURE-

Sounds good! I was thinking of manually doing each of the canaries for now by 
using this:
https://github.com/opentimestamps/opentimestamps-client. Git integration can be 
done later.

I just used the javascript opentimestamps client to stamp all the Qubes PGP 
keys, Qubes Security Bulletins, Qubes warrant canaries, and Qubes ISO digests 
along with the signatures at my fork of qubes-secpack: 
https://github.com/InnovativeInventor/qubes-secpack. Should I submit a pull 
request with these .ots files included? 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/edcb8b7a-11b6-4d84-9266-2c1e8e2292a4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-devel] Timestamp canaries

2018-03-09 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2018-03-09 16:12, Peter Todd wrote:
> On Fri, Mar 09, 2018 at 12:19:47PM -0800,
> theinnovativeinven...@gmail.com wrote:
>> I was looking at the canaries, and I liked the idea of a proof of
>> freshness with the latest news headlines. While people can't
>> create canaries ahead of time, it is possible to conspire to
>> modify or backdate one of them after they have been published. To
>> prevent this, we could use a blockchain-based timestamp, where
>> the hashes of each canary are placed within the blockchain of a
>> powerful cryptocurrency. Something similar to these services:
>> 
>> https://opentimestamps.org/ http://originstamp.org/home
>> 
>> This way, if there ever is a interruption of canaries, followed
>> by a court order or something forcing you guys to backdate a
>> falsified canary or modify old ones, we will all be able to
>> check.
> 
> The easiest way to do this is to simply use the OpenTimestamps
> (OTS) git integration. This blog post explains how:
> 
> https://petertodd.org/2016/opentimestamps-git-integration
> 
> Addiitionally, while not covered in that blog post, OTS also
> supports a mode where it rehashes the git tree in such a way that
> an efficient, SHA256-based, timestamp proof can be extracted later
> for each file. In the next release this will be done by default,
> but for now you have to add the --rehash-trees option where the
> ots-git-gpg-wrapper command is called.
> 
> FWIW, as of this week, Bitcoin Core maintainer Wladimir J. van der
> Laan started using OTS to timestamp Bitcoin Core commits and tags.
> 

Related issue:
https://github.com/QubesOS/qubes-issues/issues/2847

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlqjSZoACgkQ203TvDlQ
MDDIihAAyu8mH1+bqRR/to4nEzEsVZGP9Y2EMx0JSc2KVN3iZ/nfsoDp1h3vbLDe
r79AZAJZVvjB6VEJCyMgqfa9ZirwT3Ri0g/9ozN9XFn3gdNt1rkz21lsW/nabtpV
P0lLoPOOcCaLWiHHXbRBa3RrntOYp1f3ReFRg0+He9QcmD8aATm43euaPZ+Y/OMb
jhskfSLu9jHh4Ef0R+wXYnjtN7FNwuccy+WuByTzmlT2BbLfjTljo4pahEaDqPKo
mkX330EhVYEXmNfTiV07MmFmYtd2/9zAWB2cZCYsv7S0dh5dc3MyGzQW+pscNyMU
JroXQOtC1JgqctQSkKVPNAiGjzrz5e+RL8K6E+xpCh8tvDNZtPbcCC5S91AsvdOj
N9cxyFFWZiOq7FVO0Wjg0Rvamm67uLFRyLYVPCNj6KeZ6wsPspU32OqCZtXkVTNW
BnGts+Ooo7Z8JW0vsHo/n3kcTYhMp40sBtl4dI1oKMrkoYR8LjM2H98wecdZKl9i
kArYv8WQzgGAFn0631Z3pPRw2g9kVkssH0vrOMuDxYCLiqFg8ImIbx0AhMtPlTEA
pGYsYrL/V2OgvjBGNFcfmtTtprY8SGUFAcIBrVZUcAH4lGntLJW8D2MSmhy+9bpy
8cbbhdqeqHSI5meVyaVahL+7GCx4/gggivvd81WdY0lVkZTjpCE=
=Oc4Y
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/298ba99b-eed0-73ec-3e4a-40fa604403aa%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-devel] Re: Firewall fixes not in 4.0rc5 stable repo

2018-03-09 Thread Marek Marczykowski-Górecki
On Fri, Mar 09, 2018 at 05:04:57PM -0500, Chris Laprise wrote:
> On 03/09/2018 04:43 PM, Marek Marczykowski-Górecki wrote:
> > On Fri, Mar 09, 2018 at 04:26:26PM -0500, Chris Laprise wrote:
> > > Per issues #3260 and #3503. The commits are approaching one month old but
> > > still in current-testing. I thought they'd make it to rc5 stable.
> > 
> > Templates in rc4 have qubes-core-agent 4.0.24, which do contain those
> > commits.
> > 
> 
> I have a fedora-26-minimal template from 20171223.

There is newer one:
https://yum.qubes-os.org/r4.0/templates-itl/rpm/qubes-template-fedora-26-minimal-4.0.0-201802271926.noarch.rpm

> Freshly installed it
> updates to qubes-core-agent version 4.0.20-1. And debian-8 is updating to
> the same version.

debian-8 indeed hasn't been rebuilt for rc5.

Packages in current-testing will be migrated to current at the beginning
of next week.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/2018030936.GG4063%40mail-itl.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature


Re: [qubes-devel] Timestamp canaries

2018-03-09 Thread Peter Todd
On Fri, Mar 09, 2018 at 12:19:47PM -0800, theinnovativeinven...@gmail.com wrote:
> I was looking at the canaries, and I liked the idea of a proof of freshness 
> with the latest news headlines. While people can't create canaries ahead of 
> time, it is possible to conspire to modify or backdate one of them after they 
> have been published. To prevent this, we could use a blockchain-based 
> timestamp, where the hashes of each canary are placed within the blockchain 
> of a powerful cryptocurrency. Something similar to these services:
> 
> https://opentimestamps.org/
> http://originstamp.org/home
> 
> This way, if there ever is a interruption of canaries, followed by a court 
> order or something forcing you guys to backdate a falsified canary or modify 
> old ones, we will all be able to check.

The easiest way to do this is to simply use the OpenTimestamps (OTS) git 
integration.
This blog post explains how:

https://petertodd.org/2016/opentimestamps-git-integration

Addiitionally, while not covered in that blog post, OTS also supports a mode
where it rehashes the git tree in such a way that an efficient, SHA256-based,
timestamp proof can be extracted later for each file. In the next release this
will be done by default, but for now you have to add the --rehash-trees option
where the ots-git-gpg-wrapper command is called.

FWIW, as of this week, Bitcoin Core maintainer Wladimir J. van der Laan started
using OTS to timestamp Bitcoin Core commits and tags.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/20180309221208.GA4487%40fedora-23-dvm.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature


Re: [qubes-devel] Re: Firewall fixes not in 4.0rc5 stable repo

2018-03-09 Thread Chris Laprise

On 03/09/2018 04:43 PM, Marek Marczykowski-Górecki wrote:

On Fri, Mar 09, 2018 at 04:26:26PM -0500, Chris Laprise wrote:

Per issues #3260 and #3503. The commits are approaching one month old but
still in current-testing. I thought they'd make it to rc5 stable.


Templates in rc4 have qubes-core-agent 4.0.24, which do contain those
commits.



I have a fedora-26-minimal template from 20171223. Freshly installed it 
updates to qubes-core-agent version 4.0.20-1. And debian-8 is updating 
to the same version.


--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/0e4b4b65-68b0-866f-6a7b-d848af1333f0%40posteo.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-devel] Re: Firewall fixes not in 4.0rc5 stable repo

2018-03-09 Thread Marek Marczykowski-Górecki
On Fri, Mar 09, 2018 at 04:26:26PM -0500, Chris Laprise wrote:
> Per issues #3260 and #3503. The commits are approaching one month old but
> still in current-testing. I thought they'd make it to rc5 stable.

Templates in rc4 have qubes-core-agent 4.0.24, which do contain those
commits.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/20180309214338.GF4063%40mail-itl.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature


[qubes-devel] Firewall fixes not in 4.0rc5 stable repo

2018-03-09 Thread Chris Laprise
Per issues #3260 and #3503. The commits are approaching one month old 
but still in current-testing. I thought they'd make it to rc5 stable.


--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/cd643ed9-4997-5838-cd53-66945a2c8bc4%40posteo.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-devel] Timestamp canaries

2018-03-09 Thread theinnovativeinventor
I was looking at the canaries, and I liked the idea of a proof of freshness 
with the latest news headlines. While people can't create canaries ahead of 
time, it is possible to conspire to modify or backdate one of them after they 
have been published. To prevent this, we could use a blockchain-based 
timestamp, where the hashes of each canary are placed within the blockchain of 
a powerful cryptocurrency. Something similar to these services:

https://opentimestamps.org/
http://originstamp.org/home

This way, if there ever is a interruption of canaries, followed by a court 
order or something forcing you guys to backdate a falsified canary or modify 
old ones, we will all be able to check.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/f81fd61d-7cb4-42b6-ba99-b55f0734afbb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-devel] GPG-split like application

2018-03-09 Thread 'Raffaele Florio' via qubes-devel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

> So I'm curious about the different options that exist for implementing this, 
> and if anyone can point me towards what resources I should read up on to 
> understand what I need to do to accomplish this. Do I need to build a 
> modified Qubes in order to put this together, or is it enough to allow RPC 
> interaction via rules?

The best way is to use [0]. It's here for this purpose. So you need to write a 
server side software, a client side software and the policies. Essentially the 
server side software acts like an adapter for the wallet (you don't need either 
to modify the wallet's code).
 HTTP isn't a good idea for various reasons:
- - *more* complexity
- - 'signer' VM exposed to other VMs
- - absence of Qubes OS RPC policy
- - absence of OS's integration and so on...

[0] = https://www.qubes-os.org/doc/qrexec3/

Best Regards,
Raffaele.
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE9bU8N8AgwMcjiC1xjTxG+6f1ce4FAlqiW54ACgkQjTxG+6f1
ce4kOA//eMHrd6OnY/4ANuwlIgjVubjKirPrB0RPFIWnm6Vw9j7NH/LBBhfND6fy
zU3ChuxXZlRrkxdDxzeHhpj+i1oVqL94JVd1c/RzH+hzo5zbvlAotppi2VeUrpmE
KwxB6WKevtIp7lsP2GjeXbNWSBZNw8f9FRo+VxDijlJIG2tRmO18qLny4fQZCVik
ln2CEKZB1f/Z1SyAeH/mSA20DL7KeBoYCAJLn2mPSsPQiD9QUVykzp1Op3yk5u14
WkNxl1CHIEFhAHxZC6HyetkpDa5QOAaTUzG30/AfSlZegWgjveFOGc0/N7ilJ/6V
81MqcOCYQm1IZogVbNU57EqKnaLy2WLiQZZrNLFcL7kOoCfXlrzwqn6z39XjkaGJ
Y5lUaqZn80shbm5TTA0Y7o2hjRxzmSjN0c1+8fN097v71rCYX75+21T4pUw21Lpp
askmXG3LQ7T1wjBjCpbHjSIPBUNslMJ994QOdIvSQS0Y7eCpkB4+k+wZkiuLRcUV
Qk97RnfHCnkBybtxK9/1u0GWxVkz/Lqa/VvWTEarPAV1wwKSMbXqNP8wSR+fC+Vg
zZPT//9/eZ1HK+Rx8TIWaYrY6q2z1CNvH2O5hmrTCpoVwEsgV5gah8hxnoUOltPW
vQY/Lk+QNh/2kMqka/cnECrnlde7y/0+JNHlXArqLNr4MuKs3I4=
=JHiG
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/v_uOAvRLBHYgiwS8YiEFQlSq3Y8Oxo4WC9lm_G33fsrM3TDvCrJfSqyYXvOYYnEgR8KCSg2ZFF8wM0V4g3jUNWR12jMNKD9v5JnROpy-_KY%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-devel] GPG-split like application

2018-03-09 Thread Martin Holst Swende
Hi,

I would like to create an application that behaves very similar to how
the GPG split works. I am developing a 'signer' for Ethereum
(https://github.com/holiman/go-ethereum/tree/signer_mhs/cmd/signer),
which is basically a wallet.

The signer exposes an external API, which can be either RPC-based or
HTTP-based. The external API is considered untrusted, and all requests
to that API are handled via sign-what-you-see on the 'internal' side via
a UI of the users choice. The user can either start the signer with a
native CLI ui, or use a GUI to start the signer (in the trusted
environment), e.g the proof-of-concept QT-based poc implementation at
https://github.com/holiman/qtsigner.

Now, I would like to use a similar mechanism as gpg-split uses, in order
to have the signer running in a separate 'vault' which does not have
external networking, but does expose either RPC or HTTP to other VM:s.

So I'm curious about the different options that exist for implementing
this, and if anyone can point me towards what resources I should read up
on to understand what I need to do to accomplish this. Do I need to
build a modified Qubes in order to put this together, or is it enough to
allow RPC interaction via rules?

Cheers,

Martin Holst Swende

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/aed416f7-1225-c592-15f6-f2b492f59479%40swende.se.
For more options, visit https://groups.google.com/d/optout.


0x05A5DDF0.asc
Description: application/pgp-keys