Re: [qubes-devel] booting from USB 2.0 or 3.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Oct 15, 2016 at 11:06:34AM -0700, Chuck Bartowski wrote: > Hello, > > I was wondering if some people tried to install Qubes OS from an USB 3.0 > media. I'm asking because Paf LeGeek who made some nice tutorial videos on > youtube <https://www.youtube.com/channel/UCCSHWqosFfYJY5v2WqbTLhg> says it > is not recommended to boot from usb 3.0, better choosing an usb 2.0... > Could someone tell me why ? Didn't see the video, but my guess is that some systems have trouble booting from USB 3.0. I have at least one system, which can *sometimes* boot from USB 3.0, and I don't know why and what it depends on. There is a workaround though: you can run bootloader from USB 2.0, pick the boot option, let it load kernel and initramfs and *then* quickly remove the stick and plug it in 3.0 port. You have to do it before udev settles. - -- pozdrawiam / best regards _.-._ Wojtek Porczyk .-^' '^-. Invisible Things Lab |'-.-^-.-'| | | | | I do not fear computers,| '-.-' | I fear lack of them.'-._ : ,-' -- Isaac Asimov `^-^-_> -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJYBonTAAoJEL9r2TIQOiNR0zQP/jxj0tNhKGLiSWTRhSV2i7iW JdnKI0EuI8ME3TfHYt15HfFW1+ri/kNXBDuTr85ig5UUU+LXCNbjs/bjVqw6hzVo JUm7RAj5Jb8TjxDJRlRPZp7qhYC5Arz8Kd4fht0YD9q8RJtrP/YrgAzV1qUyGNVN 3N/Ve5q2hCexwe++eMwqjnClf5jzBVRp2pN09v01V/aZwZl24ljpKeDYrUs49Y2R OVYfOm2hBEDWeNLNifIPCFulbN/D3ODuKAWGW3olIO90ZYkSbCnzr1OpFP3tCtYb 0Q7++8+qFly3Ht9JL3wty1wd2/Ke9rPij0LG2BvCNmFgiERyWC9lrEI8opxaLJT4 joqgq2rOy9xPJ3Fw2Cyh9x8YNE3L8C0DKKdxX1okvnyVahXbAhlHDZk6hGNI4IrX YoNVfbm5YQdngpMzbVEBrHn0b1Y52Nef5D30qPnImKXwgwJJ8Ijg7px6wxXt3p1F Wam9ug+IOyEThKkDH6c+2pVHgnAMriu7vbDj4MHDv1rDFAKxUo9d/dZKQKIrv82f s70dYeF/ewiQQkovce78nOWVXPtVN4DjY3U4jVR7+NUuhvJCwWhvFjQvAMlJCq0H rFPdw6GmWDsIlBhDcaVA/NobuQwpfkKh9eRfsPI7RMt0w3gt4Ywk46ZFVrEkNARC MjwY/zE4n/PoN1GNo+26 =x33E -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/20161018204508.GV1100%40invisiblethingslab.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Standardizing tooling documentation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Dec 21, 2016 at 12:25:59AM -0800, Andrew David Wong wrote: > On 2016-12-20 13:51, Marek Marczykowski-Górecki wrote: > > On Tue, Dec 20, 2016 at 04:04:20PM -0500, Nicklaus McClendon wrote: > >> Currently, there are multiple ways manpages are generated and handled > >> for Qubes tooling, listed below are repositories that likely should > >> have manpages (primarily command line tools) (snip) > >> qubes-core-admin: pandoc (rst) and separate docs package, in doc > >> folder in repo (snip) > >> I propose that each package have a separate docs package, generated from > >> pandoc, with the source having restructured text in the doc folder in > >> each repo. > > > > I think separate doc package for man pages was a mistake. But other than > > that I agree. core-admin core3 generates manpages from RST using sphinx. This will remain that way, since it makes easier to post them also in HTML using readthedocs.io: https://qubes-core-admin.readthedocs.io/en/latest/manpages/index.html Sphinx is however specific to python. One obviously can write manpages for other tools using sphinx and rst, but there is no obvious benefit aside from nice sphinx extensions to RST. > Tracking: > > https://github.com/QubesOS/qubes-issues/issues/2528 Should I also post a comment to this bug? - -- pozdrawiam / best regards _.-._ Wojtek Porczyk .-^' '^-. Invisible Things Lab |'-.-^-.-'| | | | | I do not fear computers,| '-.-' | I fear lack of them.'-._ : ,-' -- Isaac Asimov `^-^-_> -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJYWoY0AAoJEL9r2TIQOiNRMeoP/AkNUkYTEUXFsZErXtqhAabB 5Y8QIgHb2MJMlZXhHN7XEoQcBAh9j12Co1fkwZPHaaYw66+NPlZPUthZpgd5XgJq Rsk7RZNpuDPNK5YxCgAX7FDOOEkAJdeDssOh6jOCD7fUGqIYQsOI/fQw9AG8a2IY Strk7DLWmOD57Zisw/lu3jCj6D8Vpz3KV+loQFrSG1BS4a09I8U1bzhbzwMhjfgH 2qBAmadNd4d2pIjPGbDBIEPVH0bYtpOQoAFQigQhzqfEdIlU6HdGUGOQ7wZF42w1 e9m885XA/mlkqc6Z145SrmJYfYc9/Ds9pA4EVVrZp4tXqlxtvgJ3TRoX5sxJNpLj 7oQjtL5z4cJGSqn7gylpi9I/DNirwR5wUImeaSXSYaJxMR9E7XOAYg9ZY4ZMsspz 3BTN8Foo/WzccQwpurVTUNzKWkiZlmO0xsCZ1bL9jtHBpOC6LaGu0TzwOZhqI77V HcNxZzVuo92KwbmQti035Njzo1wlqqBDxDpnFq/d8LamOnnGoJIJG2UeXDWKITAI taeWfjOa3d+i99Ak3hk1H9SqnfWvkvEzGRd3g930KvGwNTW/yvrkh1iINwZCdi+Y kmr0CZdUTc8Gp9CiQljxnnmjnR9vJcFP1cTzbYeGFiy56jahJLe4bDafKuZ+SkrO c1qzoPb2/c/i+VMiGHfP =6pys -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/20161221134006.GI1114%40invisiblethingslab.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] T-shirts at 33C3!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Dec 27, 2016 at 05:20:37AM -0800, Vít Šesták wrote: > Cool. Are you planning to make them available also for those that don't > attend CCC? We don't have specific plans, mainly because of logistic reasons (we have neither have time nor experience running a swag distribution centre on the Internet). If something remains after the Congress, we'd probably take them with us to a next conference, whichever that would be. - -- pozdrawiam / best regards _.-._ Wojtek Porczyk .-^' '^-. Invisible Things Lab |'-.-^-.-'| | | | | I do not fear computers,| '-.-' | I fear lack of them.'-._ : ,-' -- Isaac Asimov `^-^-_> -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJYYpQVAAoJEL9r2TIQOiNRnxoP/RgJosYwTu7JkmxM8z4j+x52 DEbakI8vbtqv/iMamshjhRGajtjb+imFYHnfDduW8/yb4jBk7M3O6qiG+YDmVjSw nRI6YSIHDTVz3KvhVuWwy5oFYaKMNW+TVoGrTnByS4/jgtVgAV6cg44eBY06iImf mZ9VGDFNzFwrppr/J68YIu/UMLvoog6X9KtBV8XBDsnHLCVKb+GVj8d/AA5GBNX0 2n7hGqu1GvnGBb53WkrhMCR+gvF6V/6jjIzIEalbh7WZCK1MLRjRxw6VzG4blMMt 7KbHY9MCbadc7ALdB8QZuoi2FKIC5IXMMRPdov24d0w7cwQBPQtqvXnrLZg+q+8z /LZmdwfsZHtFCwOEWI5WxQnvKuzv0BZdf2k80anRH880hzj2vT4u9EcxV8YBLYLj lsR3BPJFcc9YWhp9rhkSL4UUz0ILXRg3pCl/00JIswriynYIRzkUimAYgEdO2ZC6 9C3ETpijRC15dOPTma2yVtI3YlGoNGxFdYbG4zExg2TrOxUk3yWyymTZ5d+5nGot Z3CZcggsbopQwb9MJQQ0ypLzVPaGKm5x5OUSsQdDakkCvfppqKFTmtAdBGefVDT9 s8sZo4xyh8dgXFqlFna9MfFqLnztHW92FvAJ24fIH5ZyByu+sYe7FuyQQcunAPSM OUFf+YJak5dxmXFIIM4H =APAN -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/20161227161726.GA4382%40invisiblethingslab.com. For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Re: Signatures on devel branches & what to track for 4.0?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, Mar 23, 2017 at 02:01:34AM -0400, Jean-Philippe Ouellet wrote: > Hello, Hello, Jean-Philippe, > QubesOS/*/core3-devel branches sometimes have unsigned commits (from > woju) at HEAD. [1] These also get merged into marmarek's remotes [2], > still without signature. > > I assume this is because there are other remotes / branches actually > being used instead and tags are not propagating. Or does the automated > signature verification workflow somehow break down in practice? Woju? > Marmarek? This is because I actually don't have my signing key in the same VM as the development. Instead I use this [1] to sign my tags. I didn't write an equivalent for making signed commits. Marek keeps his signing keys in the same VM as IDE, so he signs his commits using the usual git tools. Also, marmarek has somehow elaborate script which generally pushes only his own tags to his repo. This stems from the times when we also had private git, to which we pushed proprietary code (now we don't have one for common components). Because he is the only one to push to QubesOS/* repos, those also receive only marmarek's tags. There is one exception: core-admin/core3-devel, which receives my tags using automated script. My tags are to be found in woju/* repos. Those usually work, until one of us rebases or cherry-picks something, which happens from time to time. > Anyway... my real question is what remotes & branches one should track > now if one wishes to follow work on R4.0? (Ideally in a state which > one can build a "working" system from for testing.) Marmarek posted a > builder.conf some months ago [3], but I doubt it is being used to > actually build anything since qubes-builder signature verification > would fail. There are five components which have active core3-devel branches: BRANCH_core_admin = core3-devel BRANCH_core_admin_linux = core3-devel BRANCH_core_libvirt = core3-devel BRANCH_installer_qubes_os = core3-devel BRANCH_linux_utils = core3-devel There are some other components which have had core3-devel branches which were then merged to master branches. As to which repos: Probably QubesOS, but if there is no core3-devel branch, marmarek's. I only push if I have something new, so most of my repos are outdated. I write mostly core-admin/core3-devel, so this is the most current (and most volatile) branch of this component, but there is also a bot which pushes the commits to QubesOS, and the pull requests happen there, so you may skip my repos entirely, or only fetch tags from them. [1] https://ftp.qubes-os.org/~woju/pub/qubes-rpc/git-stag https://ftp.qubes-os.org/~woju/pub/qubes-rpc/woju.GitSignTag https://ftp.qubes-os.org/~woju/pub/qubes-rpc/stag.png - -- pozdrawiam / best regards _.-._ Wojtek Porczyk .-^' '^-. Invisible Things Lab |'-.-^-.-'| | | | | I do not fear computers,| '-.-' | I fear lack of them.'-._ : ,-' -- Isaac Asimov `^-^-_> -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJY055PAAoJEL9r2TIQOiNROIwP/iiwBioOQG/htPKSiL7ZDRi/ W2vsqzVR7cRqULFxoLGQzTFYAFXbeMeYvurRnXX7eVaWiUSHqdpJuz28Qy4uWaz5 WfytKGrpCR6RPYUI584t3bvhOxow5U/WeCpbqNK5drkp8HF5sm4TiomhLl/2lTqw LtCfiaRos/zppFMxpwldd0wjVV4eugT8Jn0Xm6cILQfNMnxAyImLz/hJjY51UdgL LSdJwv9qPqe6M/pFHoFUsMiVIWbAVrCVZZVaS+7C/dg2uY/n7bzzMycucADdJtpn il6UXCUn3GJlyDZabvAZVUbzJrCgIJPysJ7cSma/v6xBlNCTvkj4qqxYi/IbGhmg ghgkPShP3zzAMlohoFtgnecfo3CdIAW2UIPDvudI9nEg+PIvYkMFvEVzXXQg759T d5I3UIs1fmFjGKFJkYsiNCGL9vphPS2RIYFVVCUs8dj+EkWSdnamUGxSZeCwL/DM cO8lA+uQnesm9wadTK1h8j9akMrSm5+36SiyYH0WveMe/gFAuJtVKcqTMK5amBPS cueceBgvGEZjEMUb17PzLzExlXUobb3WSFuHXYqU/Zn6oC3NaWK9YZyXpNEvZUW4 DVxEtBERmItB4JqgKONRU5rANSvXo925OJXEaGcUkowp3S1tiATlfEpao/z9h33k b4Noe6aUORaVhxKNrI5Y =0rJM -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/20170323100712.GN31684%40invisiblethingslab.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Re: Signatures on devel branches & what to track for 4.0?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, Mar 23, 2017 at 12:04:24PM +0100, Wojtek Porczyk wrote: > On Thu, Mar 23, 2017 at 11:31:42AM +0100, Marek Marczykowski-Górecki wrote: > > On Thu, Mar 23, 2017 at 11:07:12AM +0100, Wojtek Porczyk wrote: > > > On Thu, Mar 23, 2017 at 02:01:34AM -0400, Jean-Philippe Ouellet wrote: > > > > Hello, > > > > > > Hello, Jean-Philippe, > > > > > > > QubesOS/*/core3-devel branches sometimes have unsigned commits (from > > > > woju) at HEAD. [1] These also get merged into marmarek's remotes [2], > > > > still without signature. > > > > > > > > I assume this is because there are other remotes / branches actually > > > > being used instead and tags are not propagating. Or does the automated > > > > signature verification workflow somehow break down in practice? Woju? > > > > Marmarek? > > > > > > This is because I actually don't have my signing key in the same VM as the > > > development. Instead I use this [1] to sign my tags. I didn't write an > > > equivalent for making signed commits. Marek keeps his signing keys in the > > > same > > > VM as IDE, so he signs his commits using the usual git tools. > > > > Actually, this is not true. I use standard split-gpg and have > > gpg.program = qubes-gpg-client in .gitconfig. > > This combination didn't work before because of some deadlock, but it was > > fixed about 2 years ago :P > > Nope, the deadlock you write about was related to mutt. I wrote it about > 1 year ago, and I had a purpose for that. I think the real reason was that git > had some expectations about --switches, which splitgpg didn't fulfill. > > And I have an audit log for all commits I signed. The tool went live on Thursday, 14.01.2016 15:28:40 CET (+0100). Just checked from the log. :) - -- pozdrawiam / best regards _.-._ Wojtek Porczyk .-^' '^-. Invisible Things Lab |'-.-^-.-'| | | | | I do not fear computers,| '-.-' | I fear lack of them.'-._ : ,-' -- Isaac Asimov `^-^-_> -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJY06ypAAoJEL9r2TIQOiNRogoQAK2vNQk3vcqcwIP4Wov5H3BX GpqF+JlIJIxRrFlNIrmi9BBeIfwShduivczBMmSQRL0lzzd8ZPn1SymsZEbqbKam ROL5Bb/Z/BmhXJySibM8Z2e1lFEUxBU7MAHsSh19cx2B6TX18soSOkeWF1OpnfjG 9vpVMkQrxNRZh9Brf2/vapCyVrG0NYdg8uTYHTOfAr/aIBFi7vSori8Xsm4B5vwX QqL6H2XEvBskEaK2XVnnhsSojw43oo6iEdDwtKrTev/hMA3ZxPDdOR9AuTw6GbS0 RRxTBS8ZB8BHm5tg5SaUC8Cj+hGI3x3NOv32uL+taPJpqUPyBQDQc90rC483Jk5e RiEF/CHK7F5xVEFt4ZUnl4bxYGGGLuZElW0j6lz6W1QJGXSplUuOTL+dXKSsnj8o x1kNU0iPoiJqdcaAx/N5F9XWslUQlwLoEEdfa4TK7DP88NcvX5bOw3n/RDZLv9Ai 7e6P/JJQ1kL46RF+2EqOrFnnJL80C1M/rRxDtGIp0XDlVjz5OusSeLnGSmfekERZ 80EWT7QyTbJQThY5dJLz8+3zBTC2qLF2HIKKCEvWprFxhWaKzbE2I3QhXE3ocqkw CjWJwMQJljwDm0SZ919oCCtfhZy9RMtnDBo9ezVi7qoWaqvnGNMm6tBHrYn4w5T+ x35YzBld7imhSg6DHgcL =ngHS -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/20170323110824.GP31684%40invisiblethingslab.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Re: Managing the Qubes Documentation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Jul 08, 2017 at 03:23:22PM -0400, Jean-Philippe Ouellet wrote: > On Sat, Jul 8, 2017 at 2:45 PM, Noor Christensen > <kchr+qubes-de...@fripost.org> wrote: > > On Thu, Jul 06, 2017 at 07:40:21AM -0700, Andrew Morgan wrote: > >> On 07/04/2017 03:25 PM, je wrote: > >> > Hello, > >> > > >> > we should have a mechanism to manage the state of the documentation. The > >> > documentation is only helpful if the documents reflect the actual > >> > situation of Qubes OS. For example, documents which are written for > >> > Qubes v1 or 2 are outdated. Wikipedia displays certain meta information > >> > above articles which are outdated and/or need to be reviewed to reflect > >> > the latest changes. My idea is to have a similar mechanism. For example, > >> > it would be helpful to look after every Qubes OS, Fedora or Debian > >> > release through the documentation and mark the documents which need to > >> > be updated for the new release. In addition, it would be helpful to > >> > create an issue for every outdated document. This way it would be easy > >> > for the community to contribute to the documentation. > >> > > >> Additionally documentation version snapshots would be great. Being able > >> to choose a version of the docs from a dropdown list for each QubesOS > >> version would help keep things less cluttered as we start to have a > >> split in users using v3 and v4. > > > > I think this is a better alternative than keeping a single document up > > to date with the latest changes. > > > > Since we are using plaintext as backend for the docs, we could use git > > branches or tags to juggle the versions. When we generate the output > > HTML files the branch or tag name could be used as path prefix or > > suffix, like this: > > > > [branch qubes-doc/3.2] https://www.qubes-os.org/doc/3.2/usb/ > > [branch qubes-doc/4.0] https://www.qubes-os.org/doc/4.0/usb/ > > > > The build script could also add this version information as some widget > > in the output HTML, like dropdown at the top of each page that > > automatically selects the current version. We don't even need Javascript > > for that... ;-) > > > > -- noor > > I see two main problems with such an approach: > > 1) The site is actually generated by github-pages's infrastructure, > which is a somewhat restricted process. In theory, the multiple branch > setup you propose sounds nice, and if the site was generated via our > own scripts this would indeed be easy. However, I am not aware of any > way to do this using only base jekyll with only the plugins available > via github. Well, for source documentation we use Read The Docs (https://qubes-os.readthedocs.io/projects/core-admin/en/latest/) and they have version support built in. The source lives in either several branches, one branch with tags, or some combination thereof. Currently we have just one version built from current master (rtd call that "latest"), but starting with R4.0 we could keep the documentation for past versions. We did this separately from qubes-os.org and github for two reasons: one was to have documentation for the code in the same repo as the code documented, which makes keeping documentation up to date easier. Second reason was that we wanted to use Sphinx to generate documentation (at least for Python code, which is probably the only code actually documented :/). That wouldn't play with github as nice as RTD makes it. Now those reasons are why we probably don't want to have higher-level documentation together with that. For one, we have many different repos and for some high-level guide that uses several components there would be ambiguity where to put it. Also, many articles are applicable to several releases and it would be hard to maintain them in several branches in parallel. So I don't think there should be many outdated articles outside of those that are obviously version-specific (like those around releases). > 2) At the end of the day, this just creates more work. From my > perspective it seems less maintenance overhead to simply maintain > inline comments noting things may only apply to a particular Qubes > version, than it would be to try to maintain two separate but intended > to be mostly-parallel version of the same docs. This is especially > true since many updates to the docs are not specific to a particular > Qubes version, and would need to be manually applied to both branches. - -- pozdrawiam / best regards _.-._ Wojtek Porczyk .-^' '^-. Invisible Things Lab |'-.-^-.-'|
Re: [qubes-devel] Re: Managing the Qubes Documentation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Jul 09, 2017 at 01:05:30AM +0200, Wojtek Porczyk wrote: > Well, for source documentation we use Read The Docs > (https://qubes-os.readthedocs.io/projects/core-admin/en/latest/) Oh, and I forgot, that is also available as https://dev.qubes-os.org/projects/core-admin/en/latest/. Sorry for confusion, the second one is canonical. - -- pozdrawiam / best regards _.-._ Wojtek Porczyk .-^' '^-. Invisible Things Lab |'-.-^-.-'| | | | | I do not fear computers,| '-.-' | I fear lack of them.'-._ : ,-' -- Isaac Asimov `^-^-_> -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJZYWWlAAoJEL9r2TIQOiNR2/kP/0RoD5G5cdtFoZtG+qSLvKHJ +Hp9mNiFUdy9vf7cnOXjGTXULUf/JkAUHtvjUsXvua7Wx5jQVSyP/0eEEe/P8U09 RjeLAJc29hkADrZLIuS2XTt9+oTLWUj7r7BFlSMFdNqSSQ7NNOWW3r4V4/e4axBG X9M9oFgnFahsYcqsMvivVxNlyEdU76j4k0btYrmSSQkXGdzx891TwmfjYs2xAKLN asl6ve20t6i/QFLKvrSRHI+g2AJ+BWtaGxdudRawjjes7SuaIkWPDPD85/lkcide dOK6fY7rnybB8QSOaNG7iYLQh+eSY70/Mk4VLyciYcsrIxEIN1qD5wVqB0QfOtLu FUPYtoSdsDwJ9J17StKRF23qg44ga1hMYFB/BbDar6N/FBSZR7qOUQN6XMk14Uef 6t1a7q599/miBq1ue00Q2qWpa3DUlTgPk5K6AHpp+ib6DeeupsiuqhjZX3iRmFN0 NP70kBGmYCqcUl5VQKHIaL0wUWYb6fW5Ly4pnuxTwxi8xW/wBoAeE/6fzZHDZelN qex4WmgD5E3l1nykSrsLLCPPnWczorB+i7DAjelOuiXsm+4AHby6gbR9l6hrh+Sm wfUZr6aBzi2eHtcOqTh6blpz68EyZVjAXbmSmkh/Wj3uhQrBZzpT2lC/DIR8IBNl ygbhdGYnQK6UKgJKoO7O =YOxM -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/20170708230717.GM2697%40invisiblethingslab.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Qubes 4.0 built from git fails
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Jun 28, 2017 at 10:52:33PM +0200, Marek Marczykowski-Górecki wrote: > On Wed, Jun 28, 2017 at 11:31:48AM -0400, Outback Dingo wrote: > > still a struggle It wasn't easy to write, so why should it be easy to compile. /s - -- pozdrawiam / best regards _.-._ Wojtek Porczyk .-^' '^-. Invisible Things Lab |'-.-^-.-'| | | | | I do not fear computers,| '-.-' | I fear lack of them.'-._ : ,-' -- Isaac Asimov `^-^-_> -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJZVB/gAAoJEL9r2TIQOiNRDpoP/2ZZ6dBPE/0Dz0lbGvOSIhIm 9HxvC5RWKZs5qSxjiuPf/KGwPZ3NRXLeooX9lDRFMvtVR0g+9/GNK0XgQymoEGtw Zf3gDpFPXMygONBbOonfLnksVzzjM0G+UuycoNFVRUTLtiGMC4RH0woyTBsahW6o LT8jtaeNEVTJ4hfF1UCfSyMUGygit9mrhiBS+cs2ip23tYfuH1U95N/HpKxvI+Xq GTDktlW7PSel88lgGSWH1QlnMJBLaOp8zMwc0bm9cTh/Uf+0wlZPGkU9svT7Aef9 nSuqUU9hrPMH6WOmLvJMkgYKfV+HuPRIXucDdp/li0brjiApA46l14J/KMgKeqK5 hRKmvo8wecVEsgI9sWZTgzTxqAHy8aLAIa9zWw05wYYtJ/u0QU70FHiSphsWJkfW YE9ACKbtQQtPWfpMSETctXKMGdeBgE9ZadUEZ3pCdxIcVMXAhSuWAiwt+3TB3IGH l0QuM7Nbkiuh0j2E3M3d+yM1CfjNdaXTK+zAqWFYq7lvp5v2/YGb253J9e55vXrC xEJ4xn5Nvh5n4G2eu7tHb1XAXVLQmZ89j0HgWdLK0rzoubYPNZJWQxtUjCKfdi5G zCxNzR73BXdS27c6iRNoqPTqJGgK4TVpWgk8wU4TTVKklRbFBN981w/2g0lKVS8u e90Rz91+zuzhlw3aqMiS =rZaS -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/20170628213007.GE2697%40invisiblethingslab.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Qubes 4.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Jun 28, 2017 at 04:40:53PM -0400, Outback Dingo wrote: > Does Anyone have a recent build iso of Qubes 4.0 I can try, Ive tried > building it unsuccessfully drama in another thread. I just want to > verify my networking issues are resolved. I don't think it exists. The one I'm currently working off has non-installable templates (rpms from R3.2 can't be used on R4.0 because of some problems with post-installation, so I run the internal tools more or less manually) and there is no Manager. And bugs. Not much, but some annoying. Looks like we're going to deliver on Andrew's promise with a slight delay. - -- pozdrawiam / best regards _.-._ Wojtek Porczyk .-^' '^-. Invisible Things Lab |'-.-^-.-'| | | | | I do not fear computers,| '-.-' | I fear lack of them.'-._ : ,-' -- Isaac Asimov `^-^-_> -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJZVCKRAAoJEL9r2TIQOiNRz9oP/jooiVHbwAyNUQ/weVIlrFY7 ETLpgvDASqGNqUCxD0CXlKA4UB1oA8VvkJAhYSfDKJ5dQ1JzvC5Lkfe8CVuUqhUz yKwJUoBjmj2OSeW/5klKgZ9IE/kcXB2aCw37pXM7IZA/3FtT9g7RHtH5UFeSH6zX mjyWALWVWEtuoqwFvgiV1E/1u0r7V+yvD2Ans5u/3M1wWgXBTUDGWL9zPldEZwBi 3l9GsfL6M7TO55UkEukK/jVvy489yodYO5ntDiXOQXE3DNcbsNirqHm1R/7yr0lr 8RYe5z2uiBM6Fa4hpDSLX9wmJM+i6X0m6q9WQjXvlyffpK++rvLLFjqZxIFmnmz/ rLXaEw0K7DW5vGklpRGUXhzHVraxeOjoUoBuGAbhVPMeqCEKu4LRatgMnuV3ePGI +PBq7P057cEpoztfeuyJKHLtEwPkXR2O5UY+ErmzXunMHtBp387Uz8wXcnjrKDgc HyYr4IYsNwsd2o1Dp9lwpl8WDjYQpZS5GCMlsznVe6yJEIJgnS0dbkzbAxjkYu0H DSMqTIElFUKNagf1El7WIbozZqmoGaL6EGcbTRzC/NLa7KDmZdXxnUhB4P7g/Wzv 4KT9P1s9dhxsYvVxHcvkhRASWLsiwbwF6q7f4nA9OwJ7GNEcXMGiBzyv2GyOdead cJj6Dq2d0R18yV49la4+ =jI7V -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/20170628214137.GF2697%40invisiblethingslab.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Qubes 4.0
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Thu, Jun 29, 2017 at 12:07:04AM +0200, Marek Marczykowski-Górecki wrote:
> On Wed, Jun 28, 2017 at 11:41:38PM +0200, Wojtek Porczyk wrote:
> > On Wed, Jun 28, 2017 at 04:40:53PM -0400, Outback Dingo wrote:
> > > Does Anyone have a recent build iso of Qubes 4.0 I can try, Ive tried
> > > building it unsuccessfully drama in another thread. I just want to
> > > verify my networking issues are resolved.
> >
> > I don't think it exists. The one I'm currently working off has
> > non-installable
> > templates (rpms from R3.2 can't be used on R4.0 because of some problems
> > with
> > post-installation, so I run the internal tools more or less manually) and
> > there is no Manager.
>
> Wojtek, I've already uploaded qubes-template-fedora-25 to templates-itl
> for R4.0. And unless you want to use grub installed there, it works ;)
Oooh, and
https://ftp.qubes-os.org/~marmarek/Qubes-DVD-x86_64-20170615.iso{,.asc}
could be usable? :P
- --
pozdrawiam / best regards _.-._
Wojtek Porczyk .-^' '^-.
Invisible Things Lab |'-.-^-.-'|
| | | |
I do not fear computers,| '-.-' |
I fear lack of them.'-._ : ,-'
-- Isaac Asimov `^-^-_>
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBCAAGBQJZVDXpAAoJEL9r2TIQOiNR6HkP/1Uyw78uuQRVy9KAHGAK39RS
QRP7f3hLI/uDnfG+svQd7QTdzywsq/EMKICjDZbhXDN+bAbO6AGZCkYJTdmrRSvf
pcSvepwMQXePeSHaTvmIo4DawYkbjHt+wY4hg8qDp8x2XkYtHw/CQkJ5H7YgQQGy
DbTBLYN+JZ3eqvWDbfuxIA8YKYkuyQmsGMu4JUQsKvemQm2kIFVb4awiZQ2mwCB+
3HUUA4YWGvHkmUCBtoixJ26qimMWkVsV9fq4bxkEWY5l+qVhT6f8LWRDA6QfANHV
NnuiHUJQuDGs5tc6TY+pHQTYcTST9Hvxcc3WMcgNDTnYintOWxvZUYoTOaAiigNW
sVd03HU5sY/sU5hcBl4IpEAJ9jW658gahv2vuKXKOqwuED6Mk24Q2kBsvT8VjZgL
Gc7VnkVgDQ/K//Szwfl9dBPLqyT8bzpvzCWd5y9GVuhq1e3jC2qQQCtbuBh8mel9
FK/2JUlY4pCFIPvhtXKzFrhwP3QJMtIxM5p/ssWAELEX2OPoDbaJ7dNAM0qQAdEP
iZbYyoEeAuvcjWhkGoTgGFBXGB0dy0xLCrEckp2j2/Sr3ervCWy9lfSN4tT9brwQ
OtIJU2WO1ajWP1Jzu9RcfqBt7P39j83rnjfTfAtepz+UkQOWOtpCED9LdpAS+N8R
BSP5QXkztFpe1NOHrnCu
=S6fe
-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/20170628230412.GG2697%40invisiblethingslab.com.
For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Re: Template's root volume partition table in Qubes 4.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Oct 14, 2017 at 12:22:28AM +0200, Marek Marczykowski-Górecki wrote: > There is a problem with our shiny new templates for Qubes 4.0. Partition > table there make it hard to resize root filesystem. > > Current partition layout of a template in Qubes 4.0 is: > 1. xvda1: root filesystem (almost all available space) > 2. xvda2: EFI system partition (empty, prepared for PVHv2 boot with > VM-provided kernel) > 3. xvda3: BIOS boot (grub2 installed, used when `kernel=''`) > > This makes resizing root volume hard, because one need to move xvda[23] > data to the (new) end of the disk first. Also, having partitions at all > (de facto required by grub2), makes online resize of root volume > hard/impossible. > > Proposed solution: reorder partitions to 1. ESP, 2. BIOS boot, 3. root > filesystem. This will not solve online resize problem, but will allow > offline one (with VM restart in the middle). Why won't it solve online resizing? If you're growing the last partition, it works OK. > The problem is, it is a bit late for changing such fundamental thing... > Affected components: > - template builder[1] > - initrd[2] (responsible for mounting root filesystem) > > So, at this stage, changing partition layout (dropping support for the > current one, adding support for the new one) IMO is out of the options. > The only possibility (if at all) is to add support for new layout and > keep support for the current one. In a way not breaking the current > setup. > > Alternatively, we can keep it as is (and change later - like in Qubes > 4.1). And for now document how to extend root volume manually. Something > like: > 1. Shutdown VM (TemplateVM/StandaloneVM) > 2. Use `qvm-volume` to extend root volume > 3. Set VM kernel to some version (if was set to empty - i.e. VM provided) > 3. Start VM > 4. Launch fdisk, remove all partitions > 5. Re-create partition 1 with new size - almost the whole disk - minus 202M, > set its type to "Linux" > 6. Re-create partition 2 with size 200M, set its type to "EFI system > partition" > 7. Re-create partition 3 with size 2M, set its type to "BIOS boot" > 8. Restart VM (to reload partition table) > 9. Re-install grub (`grub2-install /dev/xvda`) > 10. Restore original kernel property (if changed in step 3) > > A lot of things can go wrong in the process. > > Yet another option would be to automate the above in initrd, before > mounting root filesystem - so it is possible to reload partition table > there, without VM restart. This would require copying data of partitions > 2 & 3. Not sure if grub will survive such thing (because of moving BIOS > boot partition). It is fragile operation, too. > > Any preference, or maybe another solution? > > Tracking issue: > https://github.com/QubesOS/qubes-issues/issues/3173 > > [1] > https://github.com/QubesOS/qubes-linux-template-builder/blob/master/prepare_image#L59-L76 > - and other places there assuming root fs is on the first partition > [2] https://github.com/QubesOS/qubes-linux-utils/tree/master/dracut - -- pozdrawiam / best regards _.-._ Wojtek Porczyk .-^' '^-. Invisible Things Lab |'-.-^-.-'| | | | | I do not fear computers,| '-.-' | I fear lack of them.'-._ : ,-' -- Isaac Asimov `^-^-_> -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJZ4UmbAAoJEL9r2TIQOiNRuBQP/jmybgdQAS17qc6KE8/Mxdxc IhpPxSawlDAsH3awlR0Osw79/Dh8wAyf+d+XTqvreQAmXx5rRZXMvxY50Ax0DOXR ojw7kk29OktzJ9TO7/J9rWrd57CiLVtrLVov8ZoSxbq1odiBGVz9QNZwlibgTYLM q9Saue9yOUIE4E21PYC8qz46fQB3wKOEUwRLKDjETZNPqKDtWnz/KNy7RP0RBH0y 7WUo62IaNbpYRCumv55tx0TqwaYQI+7Jh2jPIztiC0xBzvftJbrwNu0xRI/2xgew U2c6Q9ecGbVm7RtMS5fEjiOCbD8s8b++YTSD43gjR+Mwl5MBxQEWoOyPEYA2v51t CvlwTeH6ReSbkunmbkCqzC8y6XbFt0y/b11VLTV/R9lbBGC6JB24xCseYtr4zGg+ ijmnvXBQobfimKYFYAMaf4A1BviQERjPKb1YiyoWxrowyfloIw13f0il8N1fw7UZ oElhngZ9BJIYkXuD9Xn8jaZ22AnKmOUICdDPzmoVDzU7AFa1JJpdDS3aEYR6jalT eMRqLooYwSHIU56rqg+MPVfUO08U9v2jIyyAm8+It51I2RqoeFF7u7yunSu/AMH1 18fGWlclGS9bvNi/sIdyg20zscjjdWQuGxEilfOlvpORPJ0jlYrUy/cgprx1wKk7 ijahj6lT6gWZd8PqX3ZN =FBgi -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/20171013231748.GC21553%40invisiblethingslab.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Re: Template's root volume partition table in Qubes 4.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Oct 14, 2017 at 02:06:43AM +0200, Wojtek Porczyk wrote: > On Sat, Oct 14, 2017 at 01:40:45AM +0200, Marek Marczykowski-Górecki wrote: > > On Sat, Oct 14, 2017 at 01:21:58AM +0200, Wojtek Porczyk wrote: > > > On Sat, Oct 14, 2017 at 01:20:13AM +0200, Marek Marczykowski-Górecki > > > wrote: > > > > You can't reload partition table while it is used (something from there > > > > is mounted). At least Linux doesn't support it. > > > > > > Just tested with loop device, fdisk, and ext4. Looks like it works. > > > Unless it > > > works only with loop? > > > > No, it doesn't work, at least not directly: > > (snip) > > The kernel still uses the old table. The new table will be used at the > > next reboot or after you run partprobe(8) or kpartx(8). > > > > I wonder on what conditions partprobe would work. And how would mounted > > filesystem react for it. > > I'm calling bullshit on that. Coredump follows: (...) > [root@qubes-dev tmp]# partprobe /dev/loop0 > [root@qubes-dev tmp]# echo $? > 0 (...) Look at strace of blockdev --rereadpt and partprobe. The difference is that blockdev (and I assume fdisk also, since both are from util-linux) fires ioctl(fd, BLKRRPART), but partprobe (from GNU parted) does something funny to /sys, which I didn't try to understand, but seems to work. My guess is that this is a missing feature in kernel, which parted works around. - -- pozdrawiam / best regards _.-._ Wojtek Porczyk .-^' '^-. Invisible Things Lab |'-.-^-.-'| | | | | I do not fear computers,| '-.-' | I fear lack of them.'-._ : ,-' -- Isaac Asimov `^-^-_> -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJZ4VhQAAoJEL9r2TIQOiNRmj4P/2jqcgFLMywBayUXXCrTAVIx 9KC8xQ20PFlLaI4PRU/3SvuN0yZWuuM90uy6pQ9HhNAJU35YPy7KMy9p75+GCJ/i /NiTPtmvlFY6FoiJx1llbZvl70HJNrKZUNtYmXgQtxXihC43iCYdLWGZtazp7Deb WBi8aT1W5Q8LclnNUu0OUY+TA6jFZoD6urfva9CKBKAeH6L6bFSZ0TfPxaQlFNz8 Ya7pa6Jg39eepZS8VUjU5snqkZtA164DpvMtkXz7Fi7gjXYBNK3Y5fe6nhJ5/dsu uGHlbr1CC6WNvX6Yoh26iCkthrX0BkobpIFxqoxQxExpXrc3Px3QPlK9afiM5fn2 x3l8KRlN7FN5f+izteoP6xjeukE72IhTUOhL8c8F/ceY5jnP+hnIgVTmXMkWPTyJ WnOwGO6cPraLhyxZOlOSphN+OOY0BCR8bZbMuYRzn37prxiDrSZAEAzEixuBahBL N3a4fapwUG1k9o4Pb1NPqdT26WtNibt0+n2AcL7YjUfYclRC9ET0B80QPsfj7K2k hEaaBHlok+h0//ZqiGXAzASygG+pO8SyyLeMMjwZuPxhJoK9+tK9LuD/UK2s7Igu mgdrqnZzYlTII+J6f2CWS/T964svsWWtHy4egO7L8GPOIx2joriha264fC9tImx2 BXhYmOae919Gy9Sg8rT5 =UAwV -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/20171014002031.GF21553%40invisiblethingslab.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Re: Template's root volume partition table in Qubes 4.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Oct 14, 2017 at 01:20:13AM +0200, Marek Marczykowski-Górecki wrote: > On Sat, Oct 14, 2017 at 01:17:48AM +0200, Wojtek Porczyk wrote: > > On Sat, Oct 14, 2017 at 12:22:28AM +0200, Marek Marczykowski-Górecki wrote: > > > There is a problem with our shiny new templates for Qubes 4.0. Partition > > > table there make it hard to resize root filesystem. > > > > > > Current partition layout of a template in Qubes 4.0 is: > > > 1. xvda1: root filesystem (almost all available space) > > > 2. xvda2: EFI system partition (empty, prepared for PVHv2 boot with > > > VM-provided kernel) > > > 3. xvda3: BIOS boot (grub2 installed, used when `kernel=''`) > > > > > > This makes resizing root volume hard, because one need to move xvda[23] > > > data to the (new) end of the disk first. Also, having partitions at all > > > (de facto required by grub2), makes online resize of root volume > > > hard/impossible. > > > > > > Proposed solution: reorder partitions to 1. ESP, 2. BIOS boot, 3. root > > > filesystem. This will not solve online resize problem, but will allow > > > offline one (with VM restart in the middle). > > > > Why won't it solve online resizing? If you're growing the last partition, it > > works OK. > > You can't reload partition table while it is used (something from there > is mounted). At least Linux doesn't support it. Just tested with loop device, fdisk, and ext4. Looks like it works. Unless it works only with loop? > > > The problem is, it is a bit late for changing such fundamental thing... > > > Affected components: > > > - template builder[1] > > > - initrd[2] (responsible for mounting root filesystem) > > > > > > So, at this stage, changing partition layout (dropping support for the > > > current one, adding support for the new one) IMO is out of the options. > > > The only possibility (if at all) is to add support for new layout and > > > keep support for the current one. In a way not breaking the current > > > setup. > > > > > > Alternatively, we can keep it as is (and change later - like in Qubes > > > 4.1). And for now document how to extend root volume manually. Something > > > like: > > > 1. Shutdown VM (TemplateVM/StandaloneVM) > > > 2. Use `qvm-volume` to extend root volume > > > 3. Set VM kernel to some version (if was set to empty - i.e. VM provided) > > > 3. Start VM > > > 4. Launch fdisk, remove all partitions > > > 5. Re-create partition 1 with new size - almost the whole disk - minus > > > 202M, set its type to "Linux" > > > 6. Re-create partition 2 with size 200M, set its type to "EFI system > > > partition" > > > 7. Re-create partition 3 with size 2M, set its type to "BIOS boot" > > > 8. Restart VM (to reload partition table) > > > 9. Re-install grub (`grub2-install /dev/xvda`) > > > 10. Restore original kernel property (if changed in step 3) > > > > > > A lot of things can go wrong in the process. > > > > > > Yet another option would be to automate the above in initrd, before > > > mounting root filesystem - so it is possible to reload partition table > > > there, without VM restart. This would require copying data of partitions > > > 2 & 3. Not sure if grub will survive such thing (because of moving BIOS > > > boot partition). It is fragile operation, too. > > > > > > Any preference, or maybe another solution? > > > > > > Tracking issue: > > > https://github.com/QubesOS/qubes-issues/issues/3173 > > > > > > [1] > > > https://github.com/QubesOS/qubes-linux-template-builder/blob/master/prepare_image#L59-L76 > > > - and other places there assuming root fs is on the first partition > > > [2] https://github.com/QubesOS/qubes-linux-utils/tree/master/dracut > > > > -- > 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
Re: [qubes-devel] Re: Template's root volume partition table in Qubes 4.0
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sat, Oct 14, 2017 at 01:40:45AM +0200, Marek Marczykowski-Górecki wrote:
> On Sat, Oct 14, 2017 at 01:21:58AM +0200, Wojtek Porczyk wrote:
> > On Sat, Oct 14, 2017 at 01:20:13AM +0200, Marek Marczykowski-Górecki wrote:
> > > You can't reload partition table while it is used (something from there
> > > is mounted). At least Linux doesn't support it.
> >
> > Just tested with loop device, fdisk, and ext4. Looks like it works. Unless
> > it
> > works only with loop?
>
> No, it doesn't work, at least not directly:
>
> [root@testvm user]# truncate -s 10G test.img
> [root@testvm user]# losetup -f -P --show test.img
> /dev/loop0
> [root@testvm user]# fdisk /dev/loop0
> (...)
> Created a new partition 1 of type 'Linux' and of size 10 GiB.
>
> Command (m for help): w
> The partition table has been altered.
> Syncing disks.
>
> [root@testvm user]# blockdev --rereadpt /dev/loop0
> [root@testvm user]# mkfs /dev/loop0p1
> (...)
> [root@testvm user]# mount /dev/loop0p1 /mnt
> [root@testvm user]# truncate -s 20G test.img
> [root@testvm user]# losetup -c /dev/loop0
> [root@testvm user]# fdisk /dev/loop0
> (...)
> Command (m for help): p
> Disk /dev/loop0: 20 GiB, 21474836480 bytes, 41943040 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: dos
> Disk identifier: 0x75e36dce
>
> Device Boot Start End Sectors Size Id Type
> /dev/loop0p1 2048 41943039 41940992 20G 83 Linux
>
> Command (m for help): w
> The partition table has been altered.
> Calling ioctl() to re-read partition table.
> Re-reading the partition table failed.: Device or resource busy
>
> The kernel still uses the old table. The new table will be used at the
> next reboot or after you run partprobe(8) or kpartx(8).
>
> I wonder on what conditions partprobe would work. And how would mounted
> filesystem react for it.
I'm calling bullshit on that. Coredump follows:
- -- >8 --
Command (m for help): n
Partition type
p primary (2 primary, 0 extended, 2 free)
e extended (container for logical partitions)
Select (default p):
Using default response p.
Partition number (3,4, default 3):
First sector (43008-195311, default 43008):
Last sector, +sectors or +size{K,M,G,T,P} (43008-195311, default 195311): +50M
Created a new partition 3 of type 'Linux' and of size 50 MiB.
Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Re-reading the partition table failed.: Invalid argument
The kernel still uses the old table. The new table will be used at the next
reboot or after you run partprobe(8) or kpartx(8).
[root@qubes-dev tmp]# partprobe /dev/loop0
[root@qubes-dev tmp]# ls -ld /dev/loop0*
brw-rw 1 root disk 7, 0 Oct 14 01:16 /dev/loop0
brw-rw 1 root disk 259, 0 Oct 14 01:16 /dev/loop0p1
brw-rw 1 root disk 259, 1 Oct 14 01:16 /dev/loop0p2
brw-rw 1 root disk 259, 2 Oct 14 01:16 /dev/loop0p3
[root@qubes-dev tmp]# blockdev --getsize64 /dev/loop0p3
52428800
[root@qubes-dev tmp]# resize2fs /dev/loop0p3
resize2fs 1.43.3 (04-Sep-2016)
Filesystem at /dev/loop0p3 is mounted on /mnt; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/loop0p3 is now 51200 (1k) blocks long.
[root@qubes-dev tmp]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/dmroot 9.5G 4.6G 4.5G 51% /
/dev/xvdd 477M 227M 226M 51%
/usr/lib/modules/4.9.45-21.pvops.qubes.x86_64
devtmpfs145M 0 145M 0% /dev
tmpfs 1.0G 0 1.0G 0% /dev/shm
tmpfs 153M 616K 152M 1% /run
tmpfs 153M 0 153M 0% /sys/fs/cgroup
tmpfs 1.0G 76M 949M 8% /tmp
/dev/xvdb 197G 168G 30G 85% /rw
tmpfs31M 12K 31M 1% /run/user/1000
/dev/loop0p3 48M 650K 45M 2% /mnt
[root@qubes-dev tmp]# truncate -s 1G hda1
[root@qubes-dev tmp]# losetup -c /dev/loop0
[root@qubes-dev tmp]# blockdev --getsize64 /dev/loop0
1073741824
[root@qubes-dev tmp]# fdisk /dev/loop0
Welcome to fdisk (util-linux 2.28.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Command (m for help): p
Disk /dev/loop0: 1 GiB, 1073741824 bytes, 2097152 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x75b4ec65
Device Boot StartEnd Sectors Size Id Type
/dev/loop0p1 204
Re: [qubes-devel] Re: Template's root volume partition table in Qubes 4.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Oct 14, 2017 at 05:42:39AM +0100, Andrew Clausen wrote: > Hi all, > > On 14 October 2017 at 01:20, Wojtek Porczyk <w...@invisiblethingslab.com> > wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > On Sat, Oct 14, 2017 at 02:06:43AM +0200, Wojtek Porczyk wrote: > > > On Sat, Oct 14, 2017 at 01:40:45AM +0200, Marek Marczykowski-Górecki > > wrote: > > > > On Sat, Oct 14, 2017 at 01:21:58AM +0200, Wojtek Porczyk wrote: > > > > > On Sat, Oct 14, 2017 at 01:20:13AM +0200, Marek Marczykowski-Górecki > > wrote: > > > > > > You can't reload partition table while it is used (something from > > there > > > > > > is mounted). At least Linux doesn't support it. > > > > > > > > > > Just tested with loop device, fdisk, and ext4. Looks like it works. > > Unless it > > > > > works only with loop? > > > > > > > > No, it doesn't work, at least not directly: > > > > > > > > (snip) > > > > > > The kernel still uses the old table. The new table will be used at > > the next reboot or after you run partprobe(8) or kpartx(8). > > > > > > > > I wonder on what conditions partprobe would work. And how would mounted > > > > filesystem react for it. > > > > > > I'm calling bullshit on that. Coredump follows: > > > > (...) > > > > > [root@qubes-dev tmp]# partprobe /dev/loop0 > > > [root@qubes-dev tmp]# echo $? > > > 0 > > > > (...) > > > > Look at strace of blockdev --rereadpt and partprobe. The difference is that > > blockdev (and I assume fdisk also, since both are from util-linux) fires > > ioctl(fd, BLKRRPART), but partprobe (from GNU parted) does something funny > > to > > /sys, which I didn't try to understand, but seems to work. > > > > My guess is that this is a missing feature in kernel, which parted works > > around. > > > > I am a Qubes user, and coincidentally, the original author of partprobe > (and parted). I haven't looked at partprobe/parted since 2005. The code > has changed a lot since then, but let me do my best... > > The BLKRRPART ioctl is no good because it can't accommodate busy block > devices at all, i.e. resizing partition 1 when partition 2 on the same disk > is mounted. > > Instead, Parted primarily uses the BLKPG family of ioctl to inform the > kernel of partition table changes. (It also has "new" support for the > device mapper -- but that's probably not relevant here.) You can read > about the BLKPG ioctl in /usr/include/linux/blkpg.h. Since 2012, the linux > kernel supports a new BLKPG feature to do online partition resizing, i.e. > telling the kernel to modify a mounted partition. I think this is what is > being used here. > > The relevant Parted code is in the function linux_disk_commit(), which > calls _disk_sync_part_table() and _blkpg_resize_partition() inside > http://git.savannah.gnu.org/cgit/parted.git/tree/libparted/arch/linux.c > > If the BLKPG ioctl fails, then partprobe/parted will throw an exception and > tell you about it. Thank you for your insight. I pasted the above to https://github.com/QubesOS/qubes-issues/issues/3173#issuecomment-336635237. > Wojtek: what part of your shell transcript was unexpected? It looked like > everything worked to me. Yes, it did. The "bullshit" comment was in reply to Marek's statement about supposed inability to reread partition table while any partition is mounted. Well, as you point out, it can't be reloaded using BLKRRPART ioctl, which is used by fdisk. Marek didn't use the partprobe, and he just took the error message from fdisk at face value and concluded that we need to reboot. - -- pozdrawiam / best regards _.-._ Wojtek Porczyk .-^' '^-. Invisible Things Lab |'-.-^-.-'| | | | | I do not fear computers,| '-.-' | I fear lack of them.'-._ : ,-' -- Isaac Asimov `^-^-_> -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIbBAEBCAAGBQJZ4hJ6AAoJEL9r2TIQOiNRK+cP8QFb36PkY3+hmdlostS1Nqa2 QE1men8VxZmniwMtpUl9XRdWWYZpgsZy3OZ7M+WXncWQGzQNBk+3UIcJUC4chYS7 hR9rTLQpkV5g7fZmP8QCQukgG5SfJFhAcsBvl00WK+b7g46fIeaikWoQ2AgwZuTa ZNnZLyJPOOp4W/93HxEkeQapgoe/arL+4R0F3SRnPloGI1bac8wHZUpPa5Y69hTO +evN7Ibkt4VWkRlQm/rjKn6cF070B+VwThvxEvIbQtXc8dMnIifhxoGwjwYCWiWv q7Tws0Fgqcjr/EaRGrj/pUtPPIJkIiqKg+w6p7mNUyZSm0Ro8eXm5Z4ywJCZjJ55 vC5Z8Nl/zOOcCOIDl2u8rqA5nKR9qN4B7+IgyR6dXzYgqvvRZaNBR/FVQeu5ETMC VtuI6XgaRNeEC6EVRym+p4wh9ARIiw84QgJF0MJ8GgTXBHvNU10WroQTC68bCJNJ gSEVHW8jNR5ccUA
Re: [qubes-devel] Re: Template's root volume partition table in Qubes 4.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Oct 14, 2017 at 03:36:05PM +0200, Marek Marczykowski-Górecki wrote: > Thanks for the explanation. > This should be enough for the online resize part. Now, back to the main > issue here: partition to resize isn't the last one, one need to move two > other partitions first. Hmm, maybe parted can do that too? Can't we change the partition order and add some compatibility to initrd? We could support resizing only for "new" templates and leave the instruction to resize older ones in documentation, with a big scary warning that it's better to reinstall template than attempt manual resizing. - -- pozdrawiam / best regards _.-._ Wojtek Porczyk .-^' '^-. Invisible Things Lab |'-.-^-.-'| | | | | I do not fear computers,| '-.-' | I fear lack of them.'-._ : ,-' -- Isaac Asimov `^-^-_> -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJZ4himAAoJEL9r2TIQOiNRKYgP/2SvBiuC5LNv+WbUOwT40m17 zwVMUzdsuYwhXoJd7sMTM/afWEE/UpuyPXgeScENNxFwkNN1O2moNDFsKo/vl+nj SQocEWuPaXpN5DNdbbSoVyRLo+w6xXi3qNBfXIX13Q0zgVh6hCAn4QdbHh12xxqh oeRCmsnw8pdXevbsn7S7beJpCkU2kV25HfShh5OHJWtSrNE1anSICqN5kqoe9K61 BsoM47AXmQZQULFFCHGS03YiWdCbNo5n79Bu0+bO5/A0YPBKzft1HK+R51+fNOLZ iFYWmPBs7OrvsinH62lhvmIGlzjVo295DAd3xXCaUhgNIMjJ9MqSUIC0OADTmX3M xElF4dvY3cd7ipCm97yFitt60ig83j8qWZqk2e7gXrsuoNgTzGF+STaRdFl5R0WB cU7v+FWDVyOXhIQ9eEghagHa8YOMXfrj5rZsrQcF9TEhKi+NTA83zh7HO1TpyEA/ iAUeeZ0ak8RoAuFxtIxO6D05VFsqi+5zBR9lkXuSQt10emjlTuqfunNaT26S7G8B 7ZdbJbS5Iz9NwpI1+wPyIgCa90XQ7Do0prqLJDS5jKCuzXhqiJclzKfAZ2gG1qn4 uvaP7gYNBWSWgK9tQHyOnUi7E0eB4NjJhdBNZGNXeSKYqwK1EctCr2K8L6NkDc7h FPWRJ0JZ+vhEFjZ/Fn7j =xwUP -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/20171014140111.GH21553%40invisiblethingslab.com. For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Re: core3 event names
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Wed, Dec 13, 2017 at 09:19:59PM -0500, Jean-Philippe Ouellet wrote:
> Hello,
>
> There are some events with specific names after a colon, e.g.:
> - device-pre-attach:block
> - device-list-attached:pci
> - property-set:netvm
> etc.
>
> and sometimes the same names show up both with and without colons, e.g.:
> in core-admin/qubes/vm/__init__.py:
> self.vm.fire_event('domain-feature-delete', feature=key)
> self.vm.fire_event('domain-feature-set', feature=key, value=value,
> self.vm.fire_event('domain-feature-set', feature=key, value=value)
>
> in desktop-linux-common/qubesappmenusext/__init__.py:
> @qubes.ext.handler('domain-feature-set:internal')
>
> I think this specific with/without colons mismatch is a bug, but
> perhaps the original intention was that two events would be fired, one
> foo-bar:specific and one foo-bar, as a means of pre-filtering which
> events you care about? I could see this being useful for e.g.
> listening on generic property-setting for all properties, but idk.
If there is no explicit fire_*() with this name with colon (maybe calculated
as 'domain-feature-set:' + variable), this is a bug, and IIUC it will cause
the handler in qubesappmenuext (desktop-linux-common) not to fire.
It is a general convention that events with colon are intented as generic
classes with exact instance being named after color. This should happen at
least for devices (qubes/devices.py and qubes/ext/*), which are implemented
using extensions and communicating with events.
> Also, I wonder if perhaps event identifiers might be better as classes
> instead of strings so that we can statically catch event name
> mismatches at compile time instead of silently firing or listening for
> a typo (or other oversight) which goes nowhere / never comes.
Having this exact concern, I wrote this tool for static analysis:
https://github.com/QubesOS/qubes-core-admin/blob/master/contrib/check-events.
However it cannot be used with automatic tests, because there are some events
that no-one currently listens for and, more importantly, when I wrote this,
there were events that were fired in extensions and handled in core. I don't
know if that's still the case.
Also, the event identifiers sooner or later will have to be coerced to str,
because they are also forwarded over Admin API (see admin.Events,
https://www.qubes-os.org/doc/admin-api/). Also, I'd like to retain the
possibility to fire any event without constrain. But I see no reason not to
generate those with some predefined functions/classes/macros/whatever.
> P.S.: more documentation for qubes-core-* would be awesome
https://dev.qubes-os.org/projects/core-admin
https://dev.qubes-os.org/projects/core-admin-client
Sorry, but that's all we've got. It seems core-admin-client is currently
broken, but I don't know why.
In core-admin there are some events documented on some classes, but
1) they are not indexed AFAIK, because I don't know sphinx good enough, and
2) because they are just strings, anyone can fire any event they wish.
HTH.
- --
pozdrawiam / best regards _.-._
Wojtek Porczyk .-^' '^-.
Invisible Things Lab |'-.-^-.-'|
| | | |
I do not fear computers,| '-.-' |
I fear lack of them.'-._ : ,-'
-- Isaac Asimov `^-^-_>
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBCAAGBQJaMoE+AAoJEL9r2TIQOiNREYcP/R/42hDpF6Are0gfn1FWjiVV
RMhoqumksg8DT4wJwU/B8jxY90c6OL7z/pe2V+6I3HY5yls3igAc8h0Vlihg7whk
jxs56EG6kpdM/eTorZwq1HGp7t3kjlqgBktVeIWiGaGxwwDqni5G+qfS+Cv9SvW9
LegOA0o/vXR8c7nX5uUydXXi/v4EDDyIpYEipGGA0ue9Ha6jBdOTpvoxkaAoqOor
8IesXkEccInv0GQFsz4DXMt+kNXauX87shpx+Lcdh5V4SsIw+E1jYYlUOKJyPPJr
naJLziyd4YsI22J6G7vAhSpuq2ZqGBV57F5pbLtNeH4zgpYGmSBTvHpyw4sJZ0DG
LtO89OwIwI7xH3ehMz/D0TNRJ1FTHXwUsZEsQyzXZ9caZ6iCPfkZy8M1R6gIRZ0Z
CVFU9kgXP4wwZv3rqdTAbua65oVnZR4MRvSiKPx67pEAMjRC7iXErSX1a/aTPmIl
3ULSnKQINp9ip4dK/EC3a8cxKhfSf42bugFaxCzZc3t2UA2vvCOEsIwGITasJRNg
XLf075OyRfDKxmGrClprr6pCD2cKe1u7tHIv0ev2C95Rn3rg+yzBH1QyhwsCQRMF
q4IhE6NaMINBZVZUodxxW153L56gwtvmm9xOIJ7ybt44B+zAjI5/n0HpEHyRSdYZ
V5CpdxdNAyAoIXgQVrvZ
=YKkJ
-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/20171214134850.GG3534%40invisiblethingslab.com.
For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Re: Registering qrexec services?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Dec 03, 2017 at 11:09:21PM -0500, Jean-Philippe Ouellet wrote: > What's the intended use of [1]? > > I expected the eventual addition some kind of careful mechanism to > allow automated creation of "allow" policies by a management VM, where > the source & dest are both required to be managed by that management > VM. > > However, this seems to be an entirely different purpose. What am I missing? You're missing U2F integration repo, which is not yet public. This is part of work done for a customer, but we expect to eventually release it in public. Consider two calls: u2f.Register and u2f.Authenticate+KEYHANDLE. Just after registering, backend requests dom0 to allow respective frontend (and only that frontend) to use this particular key. This policy cannot be set from management VM, because the key is generated in hardware and needs to be communicated from the backend. But the mechanism is generic enough so there surely will be wider use for it, so it gets released now and is included as part of core stack. > [1]: > https://github.com/QubesOS/qubes-core-admin/commit/61c164e1c3feeea9342b46354636d03b5c981139 - -- pozdrawiam / best regards _.-._ Wojtek Porczyk .-^' '^-. Invisible Things Lab |'-.-^-.-'| | | | | I do not fear computers,| '-.-' | I fear lack of them.'-._ : ,-' -- Isaac Asimov `^-^-_> -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJaJTdxAAoJEL9r2TIQOiNRo2kP/jMGj4ZX63a9v9o7SF9oDLVQ JEv4XKK9vmihw6Prl+bkAoHdgzigMuyxRgPNhCqHrW2f6fQFKRGZ0nf7GziKX5vy i5KRptvDHmM/qZSDGaneLLYvcQuEyXOQ4QfYt5d2JlNjbu9JgSkSaFOE+WbN6UNh 6aVCRV/pwhY/RNhtCCvcDnCQqgkndHTTvwNrRZ4jWhLg0EdkuWI3ZLQuLqDrqM17 ES4RyJqeESf8MdB9M32mGWGgnwrIaGE9BjYv6jibj6C2KcFZ47oyPLmrl6giSge+ n+qSrLHuLrV7LNkBycmDQ8BAQcECY2Y4wYyGrXkV42kpcKv8lazz/si5MWT/wpgR qLbVX0mrexg1nXvjRhGsn71XSPEv4qaX/gcHTh0TQRj/Jdg9mdRB5XzXXzUoBMH1 JCZBe3lRoudi4xmtZV4prqZfJ0Jzy7DrOFfS+Qkr0BUEgdSpynH0GtUjArXBnKb6 XW7G0jtIA2S7HEapUN2F/gW0C7JoWsk7oQ5NL55iCuolO/mZdn6MIrpWBJh2dXPS 74jW04O+QqPZCiejTen/6tT2mrwbVwA7cnQTSDRhCIgFnofCbWLcP4cdPHXlYGEy NwZQgQ7WGMimossIocr6yfomEG6MiZ7i8AeZQk6PPW3MpJaUlYAV5M35qTNjDt8D RyIlSKGM5+yIJwP3EOOS =zpjC -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/20171204115428.GD1793%40invisiblethingslab.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Feb 20, 2018 at 04:27:16PM +0100, Tom Zander wrote: > On Tuesday, 20 February 2018 14:04:03 CET Wojtek Porczyk wrote: > > On Tue, Feb 20, 2018 at 01:21:30PM +0100, 'Tom Zander' via qubes-devel > wrote: > > > On Tuesday, 20 February 2018 01:49:37 CET Marek Marczykowski-Górecki > wrote: > > > > We've decided to deprecate the '$' character from qrexec-related > > > > usage. > > > > Instead, to denote special tokens, we will use the '@' character, > > > > which we believe is less likely to be interpreted in a special way > > > > by the relevant software. > > > > > > I would argue against the @ sign on account that it is a special > > > character in bash as well. > > > > > > I don't immediately see a way to exploit it, but why risk it? > > > > We absolutely need a special character that is not allowed in qube name to > > make the special tokens immediately obvious in policy. The process I used > > was to list available characters (POSIX Portable Character Set [1]) > [] > > If I missed something, could you please point out? I know shell just good > > enough to know that it's not possible to know every shell quirk. :) > > The thing you have to rememeber is that the escape character never needs to > be typed by the user. > In QRexec you are defining an API, applications like qvm-run are using that > API. What the user passes into qvm-run and what is actually sent to dom0 > does not have to be identical. > I guess you do the translation currently as well; '$' turns into '@' in your > new code. > > The consequence of this is that you don't have to limit yourself to the > posix list. > Using the portable characters set for a non-character simply isn't needed. > > So, knowing that your API is actually based on 8-bit characters and not 7 > bits which you are limiting yourself to, my suggestion is to take something > above 127 and below 256 as a special char. > Most fun one would be “ÿ” which is a normal character you can pass on a > shell script if you must, its actual byte-value is 0xFF Thank you for the suggestion, but I don't think it's correct. The character has to be input in at least two places: in /etc/qubes-rpc/policy as the second token (destination) on the line and as argument to qrexec-client[-vm] executable. Using any of the common editors, any language-specific keyboard layout, and any common encoding. Most people have UTF-8, or ISO-8859-*, but we don't exclude the possibility to have admin qube on Windows -- there was at least one serious attempt -- so this brings UTF-16 and Windows-125*. As and example, may I use ÿ character you provided: 1) You're right the codepoint is U+00FF, but UTF-8 encoding is actually "\xc3\xbf", so no, we cannot use it. 2) I don't have it on my keyboard. So anytime I have to input one of those characters, I search all the modifiers for the right one (ý? no. ŷ? neither. ỹ? my font has trouble with that, is that even a letter? ý? tried this one already...). I don't have real data, but I think most people don't even know where to start looking for this and in the optimistic case will end up sourcing it from gucharmap or equivalent. This is bad UX. Maybe there is a character outside portable charset that is portable and writable enough, but I don't know of any. I haven't thought there is hope enough to actually find one, so I didn't bother searching. That's why I've asked. Again, thanks for your review. I think it's helpful, because this change was made behind community's back (for obvious reasons), fast, and in very limited group of people. I wasn't sure if we didn't make some mistake, so the best what I could hope for was to explain myself and get ex post facto review, which you provided. - -- pozdrawiam / best regards _.-._ Wojtek Porczyk .-^' '^-. Invisible Things Lab |'-.-^-.-'| | | | | I do not fear computers,| '-.-' | I fear lack of them.'-._ : ,-' -- Isaac Asimov `^-^-_> -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJajVQEAAoJEL9r2TIQOiNRpbUQAJjEEAk+rKZOrFjjMkG3WQem /KNCL9gfVt3T6/keBBuEwfX3XcOIiO/FBWNfcf6dxeBGGcMHHQn0pd4Ucj/HZw8b 0/s63gjXH+ru7m4x2VW/3uDI4igkic6UUYPVHDB0sQtbTvGGWsr5pPJxcx7JgbwX +mJmDgt7i/9Y3lAGEva5ex+q7WG4hJd8ArgnJGAVnp7MrTgIduHW1/2QufC6uvvE gRRc3gbZK5FkT5Yg38UumE4sNcmnV0Nvu3m+o/g/cBcEER7wO81XW6TKFj0Ok/Bg Ostsov9NwO3iGv0usSUvMKfw7Aac3VK9SsW0r5sxA/QFe9jVvasVnmvIrxTRwwL+ W+gP5piagxgphLhUcR6LwyEhRPWzb06iDaaztXnLXyInWFEGdei1ATmlQNI0Rmno pNh/QLQqS6YF+hAl8LxSkOj3tjcg7MTYl00y9Z6ePJRUDA84s1hlWT43agWNN4L3 SX55/UzTU8DlhcduL3WmY6DVIKKlfE2Q82VorkprY6i/u/d7fdCblYLOtatZh2JB OK1ZFOprRlAJodYQMUws7o8cDgY3LxfgKX45PC23DJG6o5CDM+WoqmUw72uxMFft jRE29
Re: [qubes-devel] QSB #38: Qrexec policy bypass and possible information leak
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Feb 21, 2018 at 08:58:52PM +, Pedro Martins wrote: > On 20-02-2018 00:49, Marek Marczykowski-Górecki wrote: > >Resolution > >=== > > > >We've decided to deprecate the '$' character from qrexec-related usage. > >Instead, to denote special tokens, we will use the '@' character, > >which we believe is less likely to be interpreted in a special way > >by the relevant software. > > > > Maybe a bit late to the party No, that's fine. By that measure, whole list is late to the party, since we had to release QSB together with a working patchset for those who are not interested in bikeshedding about the character. I think this is important issue, because this QSB is result of our own mistakes and not some problem with Xen, which was generally a reccuring theme in recent bulletins. We're still before -rc5, so if someone came up with something really outstanding, we are open, though I'd prefer not to change things twice. > but I would like to suggest that instead of > using another character, you can transform something you don't control > (special characters) into something you can (normal characters). > For example, by simple encoding (after sanitation) $adminVM to text string > 2461646D696E564D (hex values of corresponding ascii character) and only > decoding it when appropriate (and you control this), you avoid > interpretation of special characters outside of where it is meaningful while > still keeping forward compatibility. This idea floated as part of internal deliberation and we decided against. The proposal differed from yours, but the argument is the same: we'd like to avoid any translation/interpretation/acting upon untrusted string as much as possible. We aim for simple code paths, and just checking the character against known value seems simpler that translating strings we don't control back and forth. That's also reason why patch for sanitisation function differs between R3.2 and R4.0: 3.2 is stable, released version and compatibility is more important (so we have translation there), but 4.0 is technically unsupported release candidate and the slight incompatibility is justified by simplified logic. - -- pozdrawiam / best regards _.-._ Wojtek Porczyk .-^' '^-. Invisible Things Lab |'-.-^-.-'| | | | | I do not fear computers,| '-.-' | I fear lack of them.'-._ : ,-' -- Isaac Asimov `^-^-_> -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJaje7fAAoJEL9r2TIQOiNRxtQP/RGWTjY+OefP1Gpa2mUkt2Sb veWPPZyXrepaNkYCXOqOSCI+qr/x+JCzCz45otdf8wes63LfYqia1wcg87eByRB9 X79VYwRQNT93cd8MxhM94hHdHBThBHaQ+72DcSBXHGnmUYwmSIbJRkLypF8yM6/S mhDooPOwc/nCNM+aDC7tAdFLyBolsgqmZ8jw28RcUHb48/IF53UUmcwixHWSm2rg LwybNNO+dsuy7OwFjgwF6dSepQ/9Yox4rwNBNT59QQHXOFqxVZcZCr3zZPJGaqpq V15/dSijLtydeNp9MMyLMZZmnlh5CQ0xkNChshnbwk7exHMROfV8wGedMUfpx5R3 +S6TknLXnZxsF9q0X07Bw5x6Kl1RSZTtAEA4kGwFmwNPOcusx1F3PhjTAGb8SGil ufFJuA/lCUnbj+hCVTsvQ9u2lah4UT29ZoBT3jZVcBkHguVSw/UGuzemq0bT9dIb ccDzFXcsaCdHKidj1NgOSv77sZutL8AFcdUvCHc6zzXjmu48PfhHGX/+mNHMRkGG o4O++k/4RBN6Hfa5RiIxyPHP1LAipOcLgLHAmMN8cgzHx8SUIVDnL1jpwgzq+yRb 2R3x0weHILtyMA/ThwjQR/j18vcwXLPdWhpb3zUohfWDz1m9856bT81QInFzrp1h 8SQF3tsjmNM6rCm3CSCO =xc94 -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/20180221221248.GO1198%40invisiblethingslab.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Tue, Feb 20, 2018 at 01:21:30PM +0100, 'Tom Zander' via qubes-devel wrote:
> On Tuesday, 20 February 2018 01:49:37 CET Marek Marczykowski-Górecki wrote:
> > We've decided to deprecate the '$' character from qrexec-related usage.
> > Instead, to denote special tokens, we will use the '@' character,
> > which we believe is less likely to be interpreted in a special way
> > by the relevant software.
>
> I would argue against the @ sign on account that it is a special character
> in bash as well.
>
> Search for it here;
> https://linux.die.net/man/1/bash
> I don't immediately see a way to exploit it, but why risk it?
We absolutely need a special character that is not allowed in qube name to
make the special tokens immediately obvious in policy. The process I used was
to list available characters (POSIX Portable Character Set [1]) and substract
the characters that are special to some relevant things:
- - qube name: a-z A-Z 0-9 _ -
- - POSIX shell [2]: |&;<>()$`\\"'*?[#~=% and the space, tab and newline
- - POSIX shell reserved words [3]: ! { }
- - non-POSIX things [3]: [ ]
- - special qrexec character: +
- - path separators (POSIX and NT): / \ :
- - regular expressions: ^. (and other already excluded)
This leaves: '\0\a\b,@'. The point is, all characters are special to
something. I'm sure if I searched for more "special" characters, I'd find them
('\0' is special to C strings, '\a' and '\b' to terminal, '@' in emails, and
',' we use in other context in policy). So I stopped there and by consensus we
picked '@'.
If I missed something, could you please point out? I know shell just good
enough to know that it's not possible to know every shell quirk. :)
[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap06.html
[2]
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02
[3]
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_04
- --
pozdrawiam / best regards _.-._
Wojtek Porczyk .-^' '^-.
Invisible Things Lab |'-.-^-.-'|
| | | |
I do not fear computers,| '-.-' |
I fear lack of them.'-._ : ,-'
-- Isaac Asimov `^-^-_>
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBCAAGBQJajBzCAAoJEL9r2TIQOiNRCvUQALLk151eBxc4URbBvWMQhTFy
24T8WygKzNutv+cIW/YlY1FVrPUcwtlJMCbj99mX45ZanHZLDNTEMKC6J1WS4tlg
SOo0r0U0SnAbUiNvKTsMiydRZDt05gmgxITRxxpCK0FN9WvxEZDF2N67XIwyd0nm
0bPyj3cguN5FJlW6dWkUS6/XoLCn6fCX6hGd0wvJFaujGcQkrL6gKYncp8dS3VfO
72hZd04vraZFaBEIg2kPhtff5jGpZaB/gI6wfZVeZKzewlHimVz/Efneh8bdeU7f
MSTqwp+RJOCIHXPxPjs3ARZQYPQIsj6XDL+UFk47sZK8p5fNRlDu9tgsWYHpMPwQ
TrvEkzAdVXHJpb6prpStfI0gLdcI9TmR8D2hCMEyHYICc9cahET3TPyVmuyKoBuf
BzLfhaLhv1mC6/aNR+/kgEAfW0ZZM8o6Dedbccz8Tuu/fc8c2A3JqlOKbVcmBc3x
9wK8CTrY08dsse8YnywbaxhK5+o01miaL3Uhf9LTbyxsVNAlvavdUWnlrxl/1e3O
2f4bTIFXLJ4jLpsmy+e0Itg1/IKnPWZs9uCouDZ8G601pz9p4ORPZJwWa9Cykllb
/PAlVwx/GJm2qPGxP4lxX2+2T2QXRhoCJTHBp9zoFyzQ7xqTFALEZtC3CRWvT1dr
t9joU8uqhcS4Wt6nA9lh
=EN6G
-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/20180220130403.GL1198%40invisiblethingslab.com.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Permission denied when using Qubes().domains
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Feb 20, 2018 at 10:45:55PM -0500, Chris Laprise wrote: > Using python3 in dom0, trying to access qubes.Qubes().domains results in the > following error: > > /dev/mapper/control: open failed: Permission denied > Failure to communicate with kernel device-mapper driver. > Incompatible libdevmapper 1.02.136 [...] and kernel driver > > It does work when using 'sudo python3' instead. > > I don't know if this is considered normal behavior or a bug, as I would > normally expect admin objects to be accessible with normal user privs. Yes, that's expected. qubes.Qubes() is meant to be used from qubesd and if you'd like to get knowledge about domains, you should use qubesadmin (even as root). See the qvm-* tools as an example. - -- pozdrawiam / best regards _.-._ Wojtek Porczyk .-^' '^-. Invisible Things Lab |'-.-^-.-'| | | | | I do not fear computers,| '-.-' | I fear lack of them.'-._ : ,-' -- Isaac Asimov `^-^-_> -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJajVXhAAoJEL9r2TIQOiNRQ1YQAJP9SdXgDgy9GklIGwlBoe+E aWbmYddrIAPMmePetXflngkm6pUgHWurTlB+ixdCdabJeDuTRfQAi31AoueKT4+M OeAwxaE+BvTTV7Pj1dQYwGbDy8YBqJuJWTNBQNDOcmo3LWamAb/dsB6p/QULJsvf sRHiKW+uB/Do9xh2okWmn2PdDLSoW//AuIMg7xbQDR2/b3i1HtKQj9o+xQIZAF1C OCmaU6OTbnmx7lmcd8inJp6tfnfjHUtNDDK7bTZAbIjejSjY333GdHkDW1s8BKBL hREQnDI0cJDE8yUgYGSssZWuPDUcP9X9ZgPLio6a0394fW8hF3HhyIKAYCmyWLLA iWbVgTsqqlx8/my7jdYXVEnBNOiJB0DRwippAH6ebfsNKw1o4kw/EyIxsu8aq6Kt 2cugO9ZU82XIQzY935JR7QFvo4olTVL/gnRiAnDYc09Zp1KU75QinbK/ueDAWfMO a8rqauHG23u32EO4pfCytARwBHhNecWPF6uDUBYOfW5/vm2Ty47xUrNDFjjoPQkK 3AwiJLXumeb/O8tiIbEMj6IcRHfRlKnvnzF/zxKrMljHF5bqCtf5+zfQE/YL/gzR nr7BWw0ma/RzR+SSYKVp653EErRbTeyBwPTnjr6GDbYBYEETjdbyN/9x21t6t9DU h43SXyH7m1VjpgDGJDPq =CeKK -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/20180221112002.GN1198%40invisiblethingslab.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Split-git?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Feb 17, 2018 at 04:01:06PM +0100, Marek Marczykowski-Górecki wrote: > On Sat, Feb 17, 2018 at 01:44:40AM -0800, Elias Mårtenson wrote: > > Has anyone considered implementing split-git? The idea being that you'd > > have a custom git protocol that forwards requests over qrexec to a git > > repository on a different vm. > > > > The reading I started thinking about it is that I have a vm for Keybase, > > and I'm using the keybase git provider for some private repositories. It > > would be nice to be able to work with those repositories from a vm which > > does not have Keybase installed. > > > > I can also envision other usecases for a split-git implementation. > > > > I have started working on a proof-of-concept but I'm nowhere near anything > > that works yet. That's why I'm asking here if anyone else have worked on > > the same thing, before spending more time on it. > > There are one and a half existing implementations of similar feature: > > 1. Running plain git protocol over qrexec: > https://www.qubes-os.org/doc/development-workflow/#git-connection-between-vms >- there is no validation of the protocol itself, only some policy for > repository access (hardcoded into the script) > > 2. Wojtek tried something similar to your idea - forwarding specific > requests over qrexec (at git object level), with data validation before > passing it to git. AFAIK this is in very early stage and very limited > scope (pushing one signed tag + dependencies?). This is my take: https://github.com/woju/qubes-app-split-git After first consulting with Marek I was under impression that this may not be that useful, but if you ask, I'm happy to share. It mostly works, but has purposefuly limited functionality. It fetches one tag. The tag has to be signed and the rest of the objects (the commit the tag points to, its tree and recursively any blobs and trees) are verified based on their SHA1. You can't fetch branches nor any other refs, but you can fetch tag and fast-forward an existing branch to it. Any objects are verified in memory before writing them to .git/objects. gpg --no-default-keyring --keyring gittrust.kpx --import < trustedpubkey.asc git remote add origin qrexec://remoteqube/repo.git?keyring=gittrust.kbx # the first time git fetch origin tag v1.0 git checkout -b master v1.0 # after some time git fetch origin tag v1.1 git merge --ff-only v1.1 I'll probably write some README to cover installation. Marek is right that this is very early stage, so bugs are very much expected. - -- pozdrawiam / best regards _.-._ Wojtek Porczyk .-^' '^-. Invisible Things Lab |'-.-^-.-'| | | | | I do not fear computers,| '-.-' | I fear lack of them.'-._ : ,-' -- Isaac Asimov `^-^-_> -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJaiwLeAAoJEL9r2TIQOiNR0rIQAJM2AEt5Fp+2f6gWoMDlcKIl +jhxQ/Yky00Y1O4OBL27ZrtfSE3A1Iy5U2bzTrW/gXbWqF31PTo/Jjq6gplL/dLF ir+jX3OhnsQumlNIc3Uqrq8TqNYI8mkezF7MOlwDFExcOKYQJfOJdjZFtNoUbwc5 nHJlB4LZhinCv3fPJ2qBWOz8fHJ+KUtOpqfxSTGG6apz+fdmRmk/r7KC6bQEzsh8 kBtGTDc9JcKI3TFncwc/KYnzUWU3mGe9nGvCwHd+6Xhsk4wmnOL0Q7emmnbt72mw Xa4QNUb0HKwoI0QboXmdQxQ1wlBDZG5B96N24p2v68HyLVsk+O4ZM0HB94aN8njH Ip5oQaHDod2cifCvwYmyBu6qYjEjKY1q3dC3vRQGBKDBmOQ1y8O9bw3aWFP6V4Ne TI5UBuL3+5hdvy7CL5bGmHditvR3LPe8+DxBjSdEklufR6EQOquxgiMlp7DY4tQg v6NeXtJR+hc7xLvhk55DhhkGuFHvkZCfqko0eDe4KQ0nAmK6DKlSv10747BTAdmQ 8kVUQbyJovjy1ejlHwrwgeM8lrjKyDABNsh9d4zHR7Ozz7zRXU1dujYn370k9agR WgUe+4wl3bpMQlhCOPsQvV3CdkG6hQhaC0lJb1jeGd06UCzAe6UCKHEWIBAbkNes I3pqLtjgsqeWmW9RwK8V =Q3LW -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/20180219170121.GK1198%40invisiblethingslab.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Permission denied when using Qubes().domains
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Mar 07, 2018 at 02:07:25AM +0100, Marek Marczykowski-Górecki wrote: > There is https://dev.qubes-os.org/projects/core-admin/en/latest/ > for qubesd side, and > https://dev.qubes-os.org/projects/core-admin-client/en/latest/ for > client side. The latter one have actual content accessible through > module index. > Generic concepts are explained in the former, client side mostly expose > subset of functions from qubesd (internally through Admin API). > > Wojtek, could you add links to both of those sites from > http://dev.qubes-os.org/? > Both are already linked from https://www.qubes-os.org/doc/ Done. Sorry for the delay. - -- pozdrawiam / best regards _.-._ Wojtek Porczyk .-^' '^-. Invisible Things Lab |'-.-^-.-'| | | | | I do not fear computers,| '-.-' | I fear lack of them.'-._ : ,-' -- Isaac Asimov `^-^-_> -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJavOePAAoJEL9r2TIQOiNRhQ8QAJWWs6XrE5vWoHlXFiHrFuTA CuhXiZbUyZqFHdRAlkrxS1UW0NSAK3rlYlyrK7Uqgu4o5CX+otpIxSyNdNZqGCJI Dv8LZnNAoQQstCoxV8r/dlurEukiZ/XwkGi3iTlHKmmCeoBqBwaitTaXm+LEfnzA C9k/nbYqNSD2lyHOzrC9zZjRFp5xp6n61DDbLbewcS3mgPa9EM6ySpBx8EXmtm2Z jSZu1grIGtTuhInqlOElp+vhKO9CjjeSQ0K/Cn7/tu0vCKxMAQ6msr5eF/Hkd34e 8onGLi0ErEn1JHbsvYloDFJdRMKAQQjB8/yemiLRueehUmoY7xYTft8E6NbmpBb5 KrC1UGb2ED1V/05dIv5FPoSg2IAPkgzm7+VHf3jcnS/PfKsWmLcXXtNUpA+j06nE DhNhGFGC0geEmqCgLdDMT2+f48WBLdHvhVla6j3P33abw3+56iSgx2HXnk/GSPK3 xF0ZfSLu0B6bsIot59ArSDmlzEg+BeAG4cnZlRQV5aiRikrAUG29Vht1Iq8Uu9L5 DDJH2CCJkA1QEckEmcWUf4ZWDqjFd2sZwm1XQclHGvAEA72ux/JHxY5lrjOHjHQO KQzpsos/bAWRwOFv/RJRMp5PX8An/RYRi/CDSoFuPEXqCWad0Y7q54+4/vR7IQiq mBchsEOrlesxPhHWG7rx =Npi6 -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/20180329131806.GA4236%40invisiblethingslab.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] I would like to add support for Awesome WM 4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Nov 05, 2018 at 04:02:35PM +0100, thor...@tutanota.com wrote: > I was considering trying to get Awesome WM 4.2 to work with Qubes. Before > I start I would like to verify with some of you who might know more than me > if there is anything in particular I should consider which might make this > difficult, or even impossible for the moment? The reason for wanting to do > this is that I would like to utilize the fake screen API in Awesome which is > only available in version 4 or higher. > It seems like Awesome 4+ packages are only available for fc26-29, and Qubes > dom0 seems to be running fc23 for Qubes 3.2 (which I am currently using) and > fc25 for 4.0. Probably won't pick up this task until I get my new hardware > and can install Qubes 4.0, which should happen in a few weeks. > Cheers See https://github.com/QubesOS/qubes-desktop-linux-awesome/pull/10. TL;DR I'd like to have same version as distro. I think it would be better to wait for fc29 in dom0: https://github.com/QubesOS/qubes-issues/issues/4225. - -- pozdrawiam / best regards _.-._ Wojtek Porczyk .-^' '^-. Invisible Things Lab |'-.-^-.-'| | | | | I do not fear computers,| '-.-' | I fear lack of them.'-._ : ,-' -- Isaac Asimov `^-^-_> -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEaO0VFfpr0tEF6hYkv2vZMhA6I1EFAlvhytkACgkQv2vZMhA6 I1F8Lw/+N6RoM7uH1wLbXN9JeTDpzoYDGGT7ZclkvsJtHbh7olfip4LwYt7iqLMm ZXvqgOwK988PN0bjEU4ZA3FfA0v5Up5txSveBCmuBrZs8B/96BuxiOLeC/czYjs6 t/J6vXSQB0Z6Kz6qce5W/UR3HcEzaly6+0HfZ4gT3FHhgabAhDgdDeLPYU/ohV+7 BOEuTmEZjxpbMskx/dxOZiDv/QCRE5nso82osyoh3GsNTKDop7oL7fuluevyo0/2 aau28t03a1+7xeW6ui4E7eYn5qm4IUtab6Lta8GasqnhzFSCVjUDV3nbzewQJ1mo S2rZeS/WLIJ7EVl3lZ7qJEIOQBtG8+YFDTEg8DJIohpFwxwVB9Bw6pMEECIRTS5e VG2yTqAcOo/PKdBPvkrHhTCJyoLe6eSN10145IUiaHpb+C0ao/vi+/MPvDgEUmBE RKSWJv5R4DbuPafkbu31iczMLYL9hBaIuNKVIWHrhV2HEL3h4aNhfCn7QIcrUdhS PtagxBAllYv6NzpeMn9zoScIciFdhLoKEGXbpJQuvwkW8y+zLYXwTVkcGIHTpFro HlqcywnhD6oWX6ca6ROI3Hlh6bfsjGrdtSCsAM3wTYX46/kHbTcbW0JWEj2vVOIZ nV+gpEo/Yk6ei9lwuzn490BzMtswF7+sHjh6EtlIhQ5PVMMIWmA= =pYL0 -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/20181106170945.rtptbxkfalgx22oo%40invisiblethingslab.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] custom libvirt xml configs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Thu, Dec 27, 2018 at 01:49:14PM +0100, Zrubi wrote:
> I need to "play" with custom xml configs, in order to get hardware
> info via dmidecode inside a VM.
(...)
> Am I missed something?
That's not how jinja template inheritance works. After {% extends %} clause
nothing is generated unless it is part of {% block %} that references
preexisting block in parent template.
http://jinja.pocoo.org/docs/2.10/templates/#template-inheritance
Only this has any effect:
> {% extends 'libvirt/xen.xml' %}
> {% block os %}
> {{ super() }}
>
> {% endblock %}
The following goes to /dev/null:
>
> {% block sysinfo %}
>
> Lenovo
>
>
> Fedora
> Virt-Manager
> 0.9.4
>
>
> LENOVO
> 20BE0061MC
> 0B98401 Pro
> W1KS427111E
>
>
> Dell Inc.
> 2.12
> 65X0XF2
> 4101
> Type3Sku1
>
>
> myappname:some arbitrary data
> otherappname:more arbitrary data
>
> {% endblock %}
>
1) and lines are not inside any {% block %}
2) there is no "sysinfo" block in parent template
For a quick-and-dirty hack, if you intend this node to be a child of
, just append it to some preexisting block using super():
{% block basic %}
{{ super() }}
{# ... #}
{% endblock %}
Alternatively, we'd accept a patch against libvirt/xen.xml to add something
like this:
{% block sysinfo %}{% endblock %}
After that patch being merged, you could write in your config:
{% extends 'libvirt/xen.ml' %}
{% block sysinfo %}
{# ... #}
{% endblock %}
- --
pozdrawiam / best regards _.-._
Wojtek Porczyk .-^' '^-.
Invisible Things Lab |'-.-^-.-'|
| | | |
I do not fear computers,| '-.-' |
I fear lack of them.'-._ : ,-'
-- Isaac Asimov `^-^-_>
-BEGIN PGP SIGNATURE-
iQIzBAEBCAAdFiEEaO0VFfpr0tEF6hYkv2vZMhA6I1EFAlwk1FsACgkQv2vZMhA6
I1H9mhAAl4nBKfOiTx9EewX3PH0yisxWCfG+WRJADeaSS107HCl73g3BObqF52t2
De6zbCRqh0hAovFBxSz7OY00py9RpboO3/nduoScQkOxMoEIfRNkzxX6yHT6HsSU
KtY9FKzhaxAGZSqeni2te+CYc0UobZkvwS/Sm3v7o6E52sctBvNkg/Sr4bzmulxo
OvvShRU//DizPi9wXjNTBwykWIgx62CsSDa9fO9SO49S/EAtULxM3X1dGp7mVfeW
8Di0dDMLZNhzm0NczVVNnJUdG3ar1C8GuZzrNwRU7/ylWSj+PEE2zHT/asTZlSdp
16KDx6bXicwIfcNwH56LUxvMy5TQ/qm26DtKmd7+TGq0V5pjtdvjxPse5D8nA/83
BKwGyKmt8KtKeXXDv7UtcMXL8CKmt2C0+ijXR1mLGxmxmLnfTAvZT1KNCA0jnqvO
aewUAHZ7YD7Zx1jBQmEJj9PjXUf+3GzadhtYygnRG755YodPrSxzpOOPbQ5zFgta
I5Mi3pq+sJY99YgIjfMSwKlvB1Ii8Dd+V1TKSdUnjnmKlEIB9GhqjH64kF7sk00P
yHleLnETvkUh/Tk38LgP5Rk6DOGZQsiZZmF3BZEI9werKpf7aSWDKeqzohPvy6do
tKnNV084Yq+XGhf7ecSRQJZv4Wi2er2Xgm0KiY5jFP+HXPaqAuk=
=6KEz
-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/20181227133211.sohk7senmnepfxb3%40invisiblethingslab.com.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] [GSoC] Template Manager: Interactions w/ Repos
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, Jul 21, 2020 at 06:31:55PM +, WillyPillow wrote: > On Monday, July 20, 2020 4:52 PM, Wojtek Porczyk > wrote: > > On Sun, Jul 19, 2020 at 06:20:06PM +, WillyPillow wrote: > > > > On another note, I'm wonder which fields are needed in the output of the > > > "info" > > > operation. Comparing my WIP code to DNF, I currently do not have the > > > architecture [2], URL, licence, and description fields. This is due to > > > `qubes.TemplateSearch` not currently returning those fields. > > > For the packages in the official repos, those fields do not contain much > > > information (in particular, the description field contains the same > > > information > > > as the summary), though I'm not sure if they might be useful in the > > > future or > > > for unofficial templates. > > > > > I don't know, could you design that so that those can be added in the future > > if need be? Those need to be understood and properly validated, because some > > software might act upon that information. For example: Debian provides > > a directory with licence texts, which allows for > > /usr/share/common-licenses/$license, which smells path traversal. > > Fedora's RPM guidelines is even worse, they support operators like "()", > > "and", "or": > > https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/ > > To include the information, all that is needed is to include it in the > `queryformat` string of the qrexec call and read it in `qvm-template` (Aside > from dealing with the newline issue [4] -- mentioned below.) > > As for validation, on our end, as we (AFAICT) only need to display the entry > as > is and don't need to parse it, we should be fine. > > For other programs parsing the information, IMO it should be up to the program > in question to sanitize its inputs. That would be in ideal world, unfortunately many developers can't be bothered to do it properly. That's why Qubes exists in the first place. > This is because the fields contain, by > design, arbitrary text, and my understanding of the linked article is that > it's > merely a guideline for Fedora repos instead of RPMs in general. Can't we make our own guidelines? Like explicit whitelist of known licences and maybe "other"? Linux templates are mostly under GPL, unikernels can have other licences, but there aren't many unikernels. Unless I'm missing something, known-good values would be easy to enumerate and check. Also, some checking probably applies also to name and description: they shouldn't have fancy characters, because UI toolkits might support things like pango markup or whatever. > > > One tricky thing is that the description may contain newlines, while `dnf > > > repoquery` does not escape them at all [3]. This may mean that another > > > method > > > of querying the repo needs to be considered if the description is > > > included. (Or > > > use unconventional characters/strings as separators. In particular, I > > > can't > > > pass NULL characters in the arguments to DNF for obvious reasons.) > > > > > Yes, another qrexec call is OK, provided this won't be too slow, i.e., to > > display a list of 15 templates available you won't refresh the repo cache > > 15 times... > > (Speaking of refreshing the repo cache, a `--refresh` option that forces this > may need to be added, either as an option to the existing qrexec calls or as > another call.) > > Creating another qrexec call is an interesting idea, but I'm unsure if it's > really feasible performance-wise. In particular, running `dnf info` (which > does > not refresh the cache by default) on any package in `qubes-template-itl` takes > almost a second on my machine. > > What I meant by "another method" is actually an alternative to `dnf > repoquery`. > The issue is that (AFAIK) DNF provides no methods other than `repoquery` to > obtain a machine-readable form of the information (short of using the API from > Python). However, it has the issue when dealing with newlines. > > IMO, the easiest way of doing this in terms of code changes is to modify > `repoquery` so that it allows expanding `\0` as null characters. Currently, it > already does similar replacements with `\n` and `\t`, and adding `\0` should > only be a one-line change. > However, I imagine that it would not be ideal to maintain a patched version of > a package in VMs. Even if the patch gets merged upstream, it'll probably still > take a few months for it to land in the next Fedora release.
Re: [qubes-devel] [GSoC] Template Manager: Interactions w/ Repos
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Thu, Jul 23, 2020 at 05:45:56PM +, WillyPillow wrote:
> One issue is that from the qrexec client side it is basically impossible to
> distinguish between the two. (Consider the case where a field contains
> `xxx\na:b:c`.)
If there are more colons that there are supposed to be, there is no need to
distinguish anything anymore, just error out for "malformed input" or
something.
In Python I like to do it with tuple assingment:
try:
field1, field2, field3 = untrusted_line.split(':')
except TypeError:
raise ParseError('error message')
It's as simple as that. The big advantage is that there aren't many ways to do
something wrong.
> Security-wise, this is unlikely to cause issues as an entity that can do this
> can probably modify the repo contents directly.
The point is, we don't know. The repo content is untrusted, and yes, attacker
can modify it. What counts is signature on RPM.
> However, if the repo, by accident, does contain packages with, say, colons in
> summaries, it may be an issue usability-wise as it's hard to give meaningful
> error messages when things break.
"Malformed input" is OK. If we break loudly, template maintainers (the honest
among them) won't publish such summary, because it will break.
> There's also the original issue with descriptions (assuming that we don't omit
> them), which contains newlines a lot of the time.
>
> That being said, if we treat such errors as "repo errors" and leave to the
> repo
> maintainers to ensure that the fields follow a certain format, then we can
> just
> use a special character for the separator [5] and ban the character from the
> fields.
Yes, and IIUC the current proposal is to have ':' as that special character.
Am I missing something?
> [5]: The separator may also need to be placed at the end of the format string.
I don't think so.
- --
pozdrawiam / best regards
Wojtek Porczyk
Graphene / Invisible Things Lab
I do not fear computers,
I fear lack of them.
-- Isaac Asimov
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEaO0VFfpr0tEF6hYkv2vZMhA6I1EFAl8bCdQACgkQv2vZMhA6
I1ElCw/8DBbV8tFs46g/7YKvGOES16ajMbV696vX4TP9rl/uJr8BZWQCu//lfJWe
XZkI4YzNn/ntL9Nb7OEcMDEPiWCMOAD86yl5mcVdYPkgDssFBBdF6hxITqyGQDfc
pYbL11v2L7P1EFWYIfrsJ8cLkQ70qgUPTc8beVGqP9DA/q2hdYnIEDdML1BWqXh6
2nWKbYAeaVj4jeWHvEjvMkvv/mLMfsyE7epZM1I2un7LbYFxBXp/+OKfmHO/+/kV
2c4xuGr0d/8IbtZsIYn+n61YfajE4idITdio3c2uxibN+FVmovWYdDeFRJSJS0FW
8iJOg/kc4nCjocNYh5CHK3HVF/geW/2GzAa/Bjip5FdnJFQNBtjlMfP2uh/2Mg2p
qyZGRYG2/cwZw67WQd/v5Wj0ZnDyyGjHdCUGo8EICIsf/fNG80Pp0gpwRwal6naZ
b5A2y4GrSBSVR85p8HNO9GROWGQW4ObQLJwQbmzav9KrSGCXq9EBF4XlQTNhaKw8
qHCi9YnPw1ph4bsailQRDB+AKOhgzo761Ne5XPjU0uFJlERz+CEadNs5c+Mjw3vv
nTXHANkqelDru8R4t5MJizcxBa29cq8WxS2hS5PC79zxAVPwfDjGVYTAnIOYAG0S
tJ5U9E4QQPDo2VzMH1XHcfM0h4K4Y4qA+kW33GP0n2xRSrh0zus=
=Dusq
-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/20200724161828.GE2122%40invisiblethingslab.com.
Re: [qubes-devel] [GSoC] Template Manager: Interactions w/ Repos
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, Jul 16, 2020 at 06:21:12PM +, WillyPillow wrote: > An initial version of the package is now at > <https://github.com/WillyPillow/qubes-repo-templates>. Just from cursory look, this also needs either PGP keys included or a dependency on a package providing those keys. Right now (4.0) those are from qubes-release and also needed in dom0 (esp. -primary are used for usual dom0 packages). Maybe the -primary key and the key for siging ITL templates should be separated? Would that be more convenient? - -- pozdrawiam / best regards Wojtek Porczyk Graphene / Invisible Things Lab I do not fear computers, I fear lack of them. -- Isaac Asimov -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEaO0VFfpr0tEF6hYkv2vZMhA6I1EFAl8RdcIACgkQv2vZMhA6 I1HHcxAAiiu/BwSl1Hx7eJAWZWHF0ax4V5umrnlCDi6MBI0giLaCml9kLyWh1JI9 FN6u7Aqi5+UUSLRgxf7kxWMo2b+W55dfvQp7/ZHD1yNMdr0jf84VxRSQGxfL5usG HH2/wRe2jMJwkcnqtGZ4F/Jn5dIee/3jJDL60YV9lMuMJYmiI9cLeTxMiMEsweZL ZI1rfKAUHYvF25mKiPxVfqxaMrnszljWmRlz+m0yKUtViRysFGi2pCvP8gyf6GZH lPAyaE87MYZ6ASlAvOZrvKaVP0w/gyrdPBTGSSvy/1efHxymHwk1OJip6bIBJWSR FiDqWeQQm5N13SmiHFWDG+j2KWxYcavecHImUIjRuzU7UL4wUEQFZYPYokNe4p8r BlajA3VN+PWnxAqZVGJWigm5dxNZbENXdBrKVpJ4J4VlR5zWrL+BRqmexpxYca0J LpuVqzB2whtaEJ0RuTuZs2/wbzsyuUSspNzGuAr9kLpH6N0iNde4MHG5D6FC/1Uz 8s3eplnAzTSSmFvQQ2kdJfFqjGXe17WrEJ/iOg1MzlhGfqUFrKXmyJ2RmK+2fZgV zVSZh6E1MpH/QXCqLIc05RkLtpgzm4RFteZygMySZhjnLMmPsKzqlmEsSoevOrVp 2FYgl2xuNE/HfdcCDVDdoGToDUSuzEDuzF+U1kpJcy3oF9PjYvE= =xrIj -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/20200717095618.GA2122%40invisiblethingslab.com.
Re: [qubes-devel] [GSoC] Template Manager: Interactions w/ Repos
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Sat, Jul 25, 2020 at 10:46:40AM +, WillyPillow wrote:
> On Saturday, July 25, 2020 12:18 AM, Wojtek Porczyk
> wrote:
> > On Thu, Jul 23, 2020 at 05:45:56PM +, WillyPillow wrote:
> >
>
> > > One issue is that from the qrexec client side it is basically impossible
> > > to
> > > distinguish between the two. (Consider the case where a field contains
> > > `xxx\\na:b:c`.)
> >
>
> > If there are more colons that there are supposed to be, there is no need to
> > distinguish anything anymore, just error out for "malformed input" or
> > something.
> >
>
> > In Python I like to do it with tuple assingment:
> >
>
> > try:
> > field1, field2, field3 = untrusted_line.split(':')
> > except TypeError:
> > raise ParseError('error message')
>
> By "distinguish between the two" I meant correct input and malformed input.
> Sorry for the confusion.
>
> The point I was trying to make in that example was that when there are colons
> *and* newlines, there could be cases like the following:
>
> ```
> field1 = 'a'
> field2 = 'b'
> field3 = 'c\nd:e:f'
> encoded = ':'.join([field1, field2, field3]) # a single entry
> encoded_list = '\n'.join([encoded] * 10) # simulate multiple entries
> # on the other side...
> decoded_list = encoded_list.split('\n') # becomes 20 rows
> for untrusted_line in decoded_list:
> field1, field2, field3 = untrusted_line.split(':') # this does not error
> out
> ```
- - Yes, this breaks something and is not distinguishable from template manager.
- - No, it's not malformed, because it conforms to specification.
- - It's OK from security perspective: You cannot cause installation of anything
the user didn't explicitly mean (by choosing an item on a list and/or
accepting a signing key).
To reiterate: in optimal case this should be avoided from the sending side,
but it't not a very high priority. It would be also OK if the tool and
specification did something like "only the first line with ':' skipped".
The worst case is something can be shown on the list of available templates
that actually cannot be installed.
> > It's as simple as that. The big advantage is that there aren't many ways to
> > do
> > something wrong.
> >
>
> > > Security-wise, this is unlikely to cause issues as an entity that can do
> > > this
> > > can probably modify the repo contents directly.
> >
>
> > The point is, we don't know. The repo content is untrusted, and yes,
> > attacker
> > can modify it. What counts is signature on RPM.
> >
>
> > > However, if the repo, by accident, does contain packages with, say,
> > > colons in
> > > summaries, it may be an issue usability-wise as it's hard to give
> > > meaningful
> > > error messages when things break.
> >
>
> > "Malformed input" is OK. If we break loudly, template maintainers (the
> > honest
> > among them) won't publish such summary, because it will break.
>
> The issue is that it's not always possible to detect such errors, as
> elaborated
> above. Of course, as long as we keep this "wart" explicit, I'm okay with
> having
> this as an "undefined behavior". (After all, the repo listing *is* considered
> untrusted anyway.)
Sure.
> > > There's also the original issue with descriptions (assuming that we don't
> > > omit
> > > them), which contains newlines a lot of the time.
> > > That being said, if we treat such errors as "repo errors" and leave to
> > > the repo
> > > maintainers to ensure that the fields follow a certain format, then we
> > > can just
> > > use a special character for the separator [5] and ban the character from
> > > the
> > > fields.
> >
>
> > Yes, and IIUC the current proposal is to have ':' as that special character.
> > Am I missing something?
>
> The reason I'm bringing this up is twofold:
>
> 1. The idea of having the repo maintainer ensure such constraints have not
> been
>explicitly brought up before AFAIK.
> 2. I'm unsure whether `:` is the best choice for this, as it's not an uncommon
>character, and banning it might be undesirable. Something like ASCII 28-31
>are possible alternatives.
I think this should be one of the printable characters, so the output is easy
to read and audit. Though ':' might well not be the best character, but there
are others like '|' or even '!' (and I'd argue banning '!' from descriptions
would do good to avoid shoutin
Re: [qubes-devel] [GSoC] Template Manager: Interactions w/ Repos
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, Jul 19, 2020 at 06:20:06PM +, WillyPillow wrote: > For the time being, the -primary and -community keys are placed in the > package. > Swapping them out for dedicated keys in the future should be fairly easy if > needed. Sure. > On another note, I'm wonder which fields are needed in the output of the > "info" > operation. Comparing my WIP code to DNF, I currently do not have the > architecture [2], URL, licence, and description fields. This is due to > `qubes.TemplateSearch` not currently returning those fields. > > For the packages in the official repos, those fields do not contain much > information (in particular, the description field contains the same > information > as the summary), though I'm not sure if they might be useful in the future or > for unofficial templates. I don't know, could you design that so that those can be added in the future if need be? Those need to be understood and properly validated, because some software might act upon that information. For example: Debian provides a directory with licence texts, which allows for /usr/share/common-licenses/$license, which smells path traversal. Fedora's RPM guidelines is even worse, they support operators like "()", "and", "or": https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/ > [2]: Probably not needed unless Qubes becomes available on other > architectures. That's a possibility, Xen supports ARM and I think we'll see more desktops/laptops on ARM in the future. But we currently don't have such plans even on a roadmap. > One tricky thing is that the description may contain newlines, while `dnf > repoquery` does not escape them at all [3]. This may mean that another method > of querying the repo needs to be considered if the description is included. > (Or > use unconventional characters/strings as separators. In particular, I can't > pass NULL characters in the arguments to DNF for obvious reasons.) Yes, another qrexec call is OK, provided this won't be too slow, i.e., to display a list of 15 templates available you won't refresh the repo cache 15 times... > [3]: Speaking of which, I'm also unsure what would happen if newlines appear > in, say, the summary field. Maybe I can conduct some experiments about this... Certainly. - -- pozdrawiam / best regards Wojtek Porczyk Invisible Things Lab I do not fear computers, I fear lack of them. -- Isaac Asimov -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEaO0VFfpr0tEF6hYkv2vZMhA6I1EFAl8VW04ACgkQv2vZMhA6 I1HeeQ//XxVfMG3n1MCMR4saAnLL9qSQdrle0KbbJd0NOV14q8eLFM/no+OiDmf7 TtxZukO6VTqrW1S4yNVoKpexAL9JfbUZTxCP3YyFuU6EFMpm1XjW1y5Io89v0bXg bq2QCVmybiPsGIAcX//y8ug6ucplm79z0um1LMDOlnmfdnW5ktwH4aL56BknON8T 2FndPpFr/9Z7QSqpoSkYykLh/RWRZqKqfEcrHEzs5RLaCnU84mMCmUWQ4yuJwaKE nceorgqMSBSPLQUQukjg8sW5NN1mhDxESpE29+8/Q59ilo6UsMRRpCJLUwu3oI9i TUcp+hXhR4UaOBa5Z7IAe5Ne5cogCd1lw6kM3rdz0bvn45qYoJ8FJKBe7G4uibqT +loM/IbP88fSl0+0sMvWANiMrIXyB/l7G7QZfY9XEAoae2TzgHPVHPgJ5t3wlA2p EsK9kqUaQwc106u+Xh/vTt86K+KVY3/mfGUMV7gdrBaXNr37sy6HqapkdEAD70Bb 2lL/cXAw9TGhX48WULeA1nxaGncfQFMA4DYvJWaLIAsmDrxwdEk7dlSDO6j6VM8o ntWYaLeHBEPt0VGVNf+j8WrlPXQ1faaOtAwR1UlX2sr37v1hzAUj07Tf+s9tnqbP egZ7h2nWW3uJHRG54LRNeViPCLA9jdKLQ2Fw+j4cX7H+ZnuNhkE= =Ivdc -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/20200720085230.GC2122%40invisiblethingslab.com.
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.
Re: [qubes-devel] Should we migrate the documentation to another platform?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, Sep 27, 2021 at 04:46:28AM -0700, Andrew David Wong wrote: > RTD: RTD, apart from sphinx, also supports mkdocs, though I've never used it. > + Built-in release-specific doc support. > + Built-in localization support. > + Supports Git for version control and history. (Presumably, we could > continue to use signed commits and tags for user and content > authentication.) > + GitHub integration. > + Supports Markdown (natively, AFAIK, though many seem to use RST). We > currently use GitHub-flavored Markdown, so some conversion may be necessary > but shouldn't be too bad. > + Built-in support for downloading/exporting docs in multiple formats for > offline reading. Direct access to human-readable Markdown source files in > Git repos should also continue to be possible. > + Includes search functionality. > + Widespread use among open-source projects. Established history. Probably > not going away anytime soon (though it could eventually, e.g., if the > project behind it ever shuts down). > + Can be self-hosted. > ? Unclear exactly how easy it'll be for users to contribute. (Almost > certainly no more difficult than it is now.) "Edit on Github" will be less friendly, because rST is a second-class citizen on github. Also, markdown is second-class citizen in sphinx. There are many things that are possible only in rST. You can mix both markup languages in a single project (not in single page), but that would require explicit policy, what should be written in which language. I've once migrated one github wiki to sphinx just by copying all GFM pages to spinx and then rewrote them one by one. > ? [Subjective] Some people think RTD looks better than a wiki. > ? Might look different from the rest of our website. Might require a > subdomain. Those two points very much depend on sphinx' theme. Wouldn't you want to port the current layout to sphinx theme? We already use RTD for dev.qubes-os.org (with sphinx, rST and one of the stock themes) and it works. With sphinx it's sometimes tricky to get rendering reproducible, i.e. `make html` on your local system renders slightly differently than the "official" build on rtfd.io. Those differences are largely limited to roles and glossaries, but are still noticeable. (At least that's my experience with sphinx-rtd-theme in another project. For compatibility with Ubuntu 18.04, said project is still stuck with Sphinx 1.8, as available in apt repo, because we also render manpages using sphinx). - -- pozdrawiam / best regards Wojtek Porczyk Gramine / Invisible Things Lab I do not fear computers, I fear lack of them. -- Isaac Asimov -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEaO0VFfpr0tEF6hYkv2vZMhA6I1EFAmFTEZYACgkQv2vZMhA6 I1FGhA/+InLJxfraA0+Ohq5EZD90Ljt4Dv+Bj/Wi9/48VkkX9LPE2teYuMJCTf+x QsDMVz5zZopWwFwnuPN8WQJLsQ5Ah5luOM8l0i2zA5UgYdG1gPycGHnJRZTLLlkr 7GvlSmfMjtwj4AZuTqQfrVkUWTQhlBZTSLkuu7/QtJeRaSlWWb990+CDecB35gxo x1XUE6LTbLa/QJPVhREjSMDreAoyfyQEQIGLxytj3Czkl7J1tnsrJ37k8ptHcLPC XyYYEVYIO6tURaIEF5Clh6Rxq5vh7lA7Yjs0q7i7AxTohJQBviQMhR6xuqK0FCnN bEPuRBnqLFK34sEnMHBCxLCRl8vfRUkU0B4WuBhxycgkDMtaF3qDyOKo/lxAn5Pq 11zsjxXvz9zx2Ujmawqi1M09POeNUjx3PfDwVGTCCFeRB0eoar0dpuLRktVarA21 wcZqFCTVy2dcIe2YDK5Hos5dQu1+bZUigSmIbYDptZ3k0ozH60D8WNx8lMa+w4Mm xRs0m5/XPSV/hSci3T86YY2aK0w3eFNInXjbW5Cw7nWGzdqXrDGh860YUD6ip2KB vkZfHNokO173KcwPBnaxciakYjakNMq3/bSf1PwZ01cOIcqULUwi8m3dEaAb+d2F ghaAXQGz43LAOZmQ0MQMcKqNMHXBMtgTvQsdu52mS6aAx02kh2Q= =jGwU -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/YVMRl1oP7CRf/Nmo%40invisiblethingslab.com.
