[qubes-devel] Re: ITL email keys
Hi Demi, On Fri, 13 Nov 2020 at 20:06, Demi M. Obenour wrote: > Thank you! That is quite helpful, although it doesn’t include the > email keys. > Oops, I missed that. Perhaps we should add in the keys from https://www.qubes-os.org/team ? I think it would be ideal to not clutter up the package though. We could just include Marek's key, which presumebly signs all the other ones? Or alternatively, perhaps security bulletins should be signed with a Qubes project key? Kind regards, Andrew -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/CAAXZBWJqYea_U6Si%2BVRCTuCvawRj5fobSM7_7mrqNtB_j5Em7g%40mail.gmail.com.
[qubes-devel] ITL email keys
On 11/13/20 7:56 AM, Andrew Clausen wrote: > Hi Demi, > > On Thu, 12 Nov 2020 at 16:26, Demi M. Obenour wrote: > >> FYI, I am not sure how to obtain the public key that signed that >> message. >> > > All Qubes keys are available inside the "distribution-gpg-keys" package, > which you can install with "dnf install distribution-gpg-keys". Since this > package is signed, it has a pretty good chain of trust built into it. > Since this is a Fedora package, it is also helpful for securely installing > Qubes from another Fedora-based distribution. > > I have been meaning to update the Qubes documentation about this, but I > have been a bit busy! > > Kind regards, > Andrew Thank you! That is quite helpful, although it doesn’t include the email keys. Sincerely, Demi -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/07366e32-37ff-0910-8f7b-ca65f362a9d1%40gmail.com. OpenPGP_0xB288B55FFF9C22C1.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [qubes-devel] QSB #61 Information leak via power sidechannel (XSA-351)
Hi Demi, On Thu, 12 Nov 2020 at 16:26, Demi M. Obenour wrote: > FYI, I am not sure how to obtain the public key that signed that > message. > All Qubes keys are available inside the "distribution-gpg-keys" package, which you can install with "dnf install distribution-gpg-keys". Since this package is signed, it has a pretty good chain of trust built into it. Since this is a Fedora package, it is also helpful for securely installing Qubes from another Fedora-based distribution. I have been meaning to update the Qubes documentation about this, but I have been a bit busy! Kind regards, Andrew -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/CAAXZBWJEJ2fcveTgxNFJRF1QByo8kNtwobmVBVuuy8Synj1dsQ%40mail.gmail.com.
Re: [qubes-devel] Travis-CI changes
Le 11/13/20 à 12:47 PM, Marek Marczykowski-Górecki a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Nov 13, 2020 at 12:35:55PM +0100, Wojtek Porczyk wrote: On Thu, Nov 12, 2020 at 11:25:16PM -0800, Andrew David Wong wrote: On 11/12/20 1:39 PM, Demi M. Obenour wrote: On 11/12/20 2:56 PM, Marek Marczykowski-Górecki wrote: As for the second opiton, why gitlab-ci? Because Frédéric done most of the integration already[2]. But there are still few options: - use gitlab.com and connect our own worker(s) - use Frédéric's gitlab instance - setup separate gitlab instance My main concern regarding which instance to use is about availability and maintenance. I'd like to avoid situation when only one person can fix things if something is broken. Believe it or not, some of us do take vacations form time to time ;) Any opinions? Any other options? GitLab CI seems to be a good choice. The GHC team has had good experiences with it, for example. Since we consider the CI to be untrusted, and since we want to minimize maintenance, I suggest using https://gitlab.com as opposed to hosting our own instance. Sincerely, Demi I agree with the GitLab CI option and using it in a way that minimizes the maintenance overhead to the greatest extent possible. Wouldn't we have to maintain our own runners anyway? I'm applying for Gitlab Gold license (free for open source projects), which includes 50k CI minutes per month. But as a fallback, yes, we'd need our runner(s). Fortunately, gitlab made this trivial. Yes preparing a runner is just few minutes and maintaining it is "just" hardware cost maintenance. Frédéric -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/548b68f4-8fc4-37b5-27fc-38a9b34f2394%40qubes-os.org. OpenPGP_0x484010B5CDC576E2.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [qubes-devel] Travis-CI changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Nov 13, 2020 at 12:35:55PM +0100, Wojtek Porczyk wrote: > On Thu, Nov 12, 2020 at 11:25:16PM -0800, Andrew David Wong wrote: > > On 11/12/20 1:39 PM, Demi M. Obenour wrote: > > > On 11/12/20 2:56 PM, Marek Marczykowski-Górecki wrote: > > > > As for the second opiton, why gitlab-ci? Because Frédéric done most of > > > > the integration already[2]. But there are still few options: > > > > - use gitlab.com and connect our own worker(s) > > > > - use Frédéric's gitlab instance > > > > - setup separate gitlab instance > > > > > > > > My main concern regarding which instance to use is about availability > > > > and maintenance. I'd like to avoid situation when only one person can > > > > fix things if something is broken. Believe it or not, some of us do > > > > take vacations form time to time ;) > > > > > > > > Any opinions? Any other options? > > > > > > GitLab CI seems to be a good choice. The GHC team has had good > > > experiences with it, for example. Since we consider the CI to be > > > untrusted, and since we want to minimize maintenance, I suggest using > > > https://gitlab.com as opposed to hosting our own instance. > > > > > > Sincerely, > > > > > > Demi > > > > > > > I agree with the GitLab CI option and using it in a way that minimizes the > > maintenance overhead to the greatest extent possible. > > Wouldn't we have to maintain our own runners anyway? I'm applying for Gitlab Gold license (free for open source projects), which includes 50k CI minutes per month. But as a fallback, yes, we'd need our runner(s). Fortunately, gitlab made this trivial. - -- 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? -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl+uckMACgkQ24/THMrX 1yxLVQf8DTpRaYkJW8WLufe8DcyHSuQgUwbwWF0mSBdLS1aAYG3rqkvPqnkEXiro 9np9kdTsktnxRSUy9lTsvE/K6Lwz3UswYsn5eUWLgBWvUARxUjTRHFYW5s6ulYbg CNIZGXuIXzCthAbSPHsg+yjS8azjFa9KsG2WX9OrUfMVWQKpktiGboUbBUfkLKIT fiNx+DLgst42K1QpusQ7PVjmeJUreL5F24eotyG3I9TtC1CZ9XeqVtuXbjiiA4rq S0LDQE9Y3BMQioRiw+1qeW05Nd9j8277FVVtoo6tIJon9SS13BpaPLL0W4C6ATbH R/E4vWWcjs18TyksLfvy0ZaYSvHCog== =kUnn -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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20201113114714.GV120921%40mail-itl.
Re: [qubes-devel] Travis-CI changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, Nov 12, 2020 at 11:25:16PM -0800, Andrew David Wong wrote: > On 11/12/20 1:39 PM, Demi M. Obenour wrote: > > On 11/12/20 2:56 PM, Marek Marczykowski-Górecki wrote: > > > Hi all, > > > > > > Recently Travis-CI have changed their limits for public repositories[1]. > > > We've used up new free monthly limit in just 3 days. They do offer extra > > > limits for some open source projects, but the project requesting it must > > > meet the following criteria: > > > > > > - - Project must be at least 3 months old and is in active development > > > (with regular commits and activity) > > > - - Project meets the OSD specification > > > - - Project must not be sponsored by a commercial company or organization > > > (monetary or with employees paid to work on the project) > > > - - Project can not provide commercial services or distribute paid > > > versions of the software > > > > > > We do not meet the third one. > > I can't help but wonder whether this is one of those situations in which the > rules have the opposite effect of the one intended. No doubt, their > intention is to make the service free for all and only open-source projects > that do valuable work but don't receive enough income to be able to afford > the service, which is exactly the situation in which the Qubes OS Project > finds itself, despite not meeting the third requirement. I think their intention is to reduce costs, and supporting FOSS is secondary to that. They left a nominal possibility for FOSS projects mainly to avoid back PR while implementing this change. The amount of hoops the projects have to jump through is significant enough that many projects will abandon travis altogether. [snip] > > > As for the second opiton, why gitlab-ci? Because Frédéric done most of > > > the integration already[2]. But there are still few options: > > > - use gitlab.com and connect our own worker(s) > > > - use Frédéric's gitlab instance > > > - setup separate gitlab instance > > > > > > My main concern regarding which instance to use is about availability > > > and maintenance. I'd like to avoid situation when only one person can > > > fix things if something is broken. Believe it or not, some of us do > > > take vacations form time to time ;) > > > > > > Any opinions? Any other options? > > > > GitLab CI seems to be a good choice. The GHC team has had good > > experiences with it, for example. Since we consider the CI to be > > untrusted, and since we want to minimize maintenance, I suggest using > > https://gitlab.com as opposed to hosting our own instance. > > > > Sincerely, > > > > Demi > > > > I agree with the GitLab CI option and using it in a way that minimizes the > maintenance overhead to the greatest extent possible. Wouldn't we have to maintain our own runners anyway? - -- pozdrawiam / best regards Wojtek Porczyk Graphene / Invisible Things Lab I do not fear computers, I fear lack of them. -- Isaac Asimov -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEaO0VFfpr0tEF6hYkv2vZMhA6I1EFAl+ub5wACgkQv2vZMhA6 I1GvoBAAgpwQ74LDRPeBvTAu9IZE2ACMwiuUB9g6t0DVlVx0yN+VBPrejqY2+9Xy xKs1Efo7qWnzdSymVtgjPWwBwZsS0UP1sAPEjhBmogFa60o+vgXMWkIMaz5HKcQh njwTXoCA9NqA6BE5lsUqGi+/qC4Z/3M5J0+Joc/5scv3IFfznmLWXW0OEUdHE0KK 8U/5p4kKWBmcMB9pKBpyFpRyb8MGRyadRj1TdRhTnao7PsqoonB9RoCYiwgaKdDz y1+Jl1mcedwxddwn2HWImUjKMWqQuRIMbaVQmut98fY5wJgHt7kAUVI3QJJUm9J7 TbAj4eeALJJAZLYtdi4Wuxj+J5mIJWysfTdlT3j61YBr9Oic7ANFy3tKyj+vqdwn x8dThmqBOSF7IlmVHCzuncjsUKro6ENe7Oc2DmciCSHMpyRKyMSBiGoYeujphPL5 SOk4n7k9EkPIZL18FR6h6uUdOpfse10gvLNbHwT5cgKdEjDONt5z6VODgYQMWCB8 PPPUokhysIVdn2+Q2FrMvMSExfivwxl/3wu3ThevuoKnzSMx6O4IQypSz3a5Ff+s vn3UBSpgj/QWjxCqXPFSozZHfsUBDLeja3o0qmZSpvGOrMVG51upvJ0whjVg38xD Opn4YDBn7+xQWtkhlejRlGfQkUJw2bgu1tV8nvWm3YhBEkZABms= =pej5 -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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20201113113555.GC21158%40invisiblethingslab.com.
