Re: [qubes-users] Runing Qubes on: HP ProBook 430 G2 or HP EliteBook 820
Linus Stridbeck wrote: > I came across very inexpensive HP computers: > > HP ProBook 430 G2 > > HP EliteBook 820 > > They both have i3 procesor and I wonder if someone tried ryning Qubes on one > of them? > > > I'm typing this on an 820 G3 with an i5 6200u cpu. Once I've had a bit more of a chance to play I'll post a proper HCL entry. My existing 3.2 install has no problems booting on the machine, the features needed for 4 are supported (SLAT/EPT and interrupt remapping), but I haven't tested 4. The CPU should support 32gb, but the manual states 16gb is the max, I currently have one 16gb stick in one ram slot and this works fine. Virtualisation needed to be turned on in the BIOS. Unlike older Elitebooks, it only seems to have a single USB controller, which is a pity, as it seems to mean ports, webcam and fingerprint reader are on the same controller, a pity as machine has interrupt remapping. Issues I'm currently working through: Screen brightness cannot be controlled using f5/f6 keys, however the brightness slider available from the power manager on the xfce system tray does control it. Webcam doesn't seem to work with cheese in fedora 26, light on webcam flashes then cheese exits. Screen backlight stays on when screen is locked. If you're looking at an older 820 with an i3, check the processor at ark https://ark.intel.com/ it's quite likely it may be missing some of the features required for Qubes / Qubes 4. V -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/eXFuzuxjvoru542I-jpWt2-KxF--sYhODPj3RIvTp570ZDreyu0S39dnKzAiYBUJVSPGCF6Tyi9PeHVxddyunDr0LMC_y-0P9IEl42i-ElA%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] noscript xss warning on qubes os site
Original Message On February 5, 2018 12:34 AM, Andrew David Wong wrote: > On 2018-02-04 09:02, 'Vincent Adultman' via qubes-users wrote: >>Confirm I get this too with noscript in firefox. Will try and get >> some details together if I can and file an issue... >> > Thank you! That would be very helpful! > > We've been investigating this problem for a while, but we haven't been > able to determine the cause. Looks like it may well be not our problem. With the below test version installed from https://noscript.net/getit#devel I no longer have the issue. Perhaps someone else could also give this version a go to confirm. v 10.1.6.5rc2 = x [XSS] More specific and unobtrusive handling of window.name sanitization -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/t_4M1Wx07fQbxh_SgcfAwBqdUuG9DW9m3nJf-oX9HI67xX4nSvnTOLA19U9FfMOYV1dPaJbz39151nyS1KgOD5_yFJVVwysnuZVdyiszP08%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] noscript xss warning on qubes os site
Confirm I get this too with noscript in firefox. Will try and get some details together if I can and file an issue... -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/wvYwPPFm2B2jzrZyAzoVWKOkOY5z4Zry7aeneQnDd7QI1TFFMT1Wv6K5o3o5b2TZ4lVH5G_pMJk_dctMlgzQZWzRAVy7D-aVnvMebexshpc%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
>> Only running VMs are vulnerable >> >> Since Qubes OS is a memory-hungry system, it seems that an attacker >> would only be able to steal secrets from VMs running concurrently with >> the attacking VM. This is because any pages from shutdown VMs will >> typically very quickly get allocated to other, running VMs and get wiped >> as part of this procedure. IIUC this still seems fairly awful from a usability perspective if we think of the added cognitive load of watching what is running when and remembering or making choices on what to close / restart when (I'm reading between the lines and guessing this has had something to do with decision on reintroduction of Qubes manager?). sys-net is considered to be likely / easily compromised (such that there seems some real utility in making it a dispvm under 4). However, it will also be running for most users in most everyday cases for long periods. A common use case for open at one time for me for internet banking might be at minimum sys-net, sys-firewall, sys-usb, vault and a dispvm (as shitty banks here often loading things off marketing or even advertising network domains changing fairly regularly). If we're saying that in an ideal situation, sys-net and sys-usb (if it has had any untrusted devices attached to it) are started clean else the secrets vault is at risk, that seems to remain a very serious problem. The other approach seems to be to store the banking secrets in a banking vm, and do the browsing as well from there. Some sensitive tasks can no doubt be done with sys-net shut down, but by no means all. If we're considering that this will be the case for quite some time(?) due to Xen approach, do we need to offer some sort of recipe situation for vm-start (where I can ensure my "red" vms are shut down or cycled before my vault is started for example). I try to pay my Qubes dues by offering assistance in IRC, and I'm anticipating here the sort of user willing to put effort into thinking about how they need to partition their domains, and maybe even write some custom rules / scripts but after that needs the system not to overly get in the way of day to day tasks / require constant tinkering. Vince -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/y4JzRn90_0mDNiNrt3Hq_kPJY6KbTxstTz8z2KvR_8ORlcJ7thJC0zOZupxxEuewcc3TnhVx5Rrz400I1B6XLy9BYjNVHinu4kNHFRn7dIU%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] 3.2.1 / An updated 3.2 iso?
Hi all We were chatting today in IRC about current user expectations and experiences with the 4 release candidates. While many are happily testing there are indeed some visitors who drop by with the requirement of a daily driver stable system, but have some newer hardware than the kernel on the current 3.2 iso will support. These users seem to be in a somewhat painful position, the bravest are attempting to build their own isos or perform some cross install using a machine that will work. Some fail / give up. https://www.qubes-os.org/doc/supported-versions/ suggests that at some point a 3.2.1 release was/is planned, h01ger suggested to me all focus is currently on 4, but can I ask: 1. What are the current plans for 3.2.1? (if it was planned to be anything other than an updated iso) 2. Regardless of 1. is there a possibility of getting an updated 3.2 iso for Christmas, given that some will undoubtedly use the holiday time to try Qubes, quite possibly on shiny new hardware :) Thanks for your time. V -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/N-1wnPOykS8pCH8sPzKe9RLHQ4fxFkfG2II-1yZdMUHiuRzDUIyJuo53uH1j30YuVS7nmj0yjRWZr6_xiPCaNirEDjD8ebGDoe4ak7n9jwc%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] kswapd0 using 100% CPU with not even a MB swap in use
>> On 10/08/2017 08:18 AM, Marek Marczykowski-Górecki wrote: > > Indeed on 4.9.45-21 kernel it happens much rarer than on 4.4.x, but still > happens sometimes... It's only anecdotal, but I seem to have been seeing it more frequently recently (i.e. on that kernel). Will try the one-liner again, don't think it had any effect last time I tried it. I've got at least one old laptop with probably poor thermal paste or a dust bunny that this actually causes to overheat and shut down in a warm room. Less critically, for what's often a laptop OS it's rather hard on the battery. FWIW (beware, anecdote incoming) the problem does seem different under the newer kernel, in that close enough other vms and the one with the problem may settle down (which I don't remember happening before). However, this makes limited sense to me, given that one vm that does it (sys-net) is not included in memory balancing, whereas others that randomly do it are. The vms that do it are fedora service vms, through to debian ones running chromium, the commonality being the kernel. A quick google suggests this occurs / or has occurred on a variety of linux distros, but I do wonder if something about a memory constrained qubes install makes it more likely. Marak, afaik there is no bug open for this, would it be worth me opening one, even if its just to track and add to a known issues page or similar? Seems enough of us run into this one. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/Gorgp-LxukU8BbuISwc7s-zJ4G_DKsvBTRFdLvEqCDWDjbDEnhSKdRC8__BxvA9AQJgowPgnij6KgP_2qImlSkAL4_2nkxpvhI_GavM3Teg%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Fedora25 fails updates unless I reboot the machine 9.13.17
I'm experiencing a similar problem which I've reported a bug for at https://github.com/QubesOS/qubes-issues/issues/3135 If you're still encountering the issue with the update proxy failing too, could you check the output of "journalctl -u qubes-updates-proxy.service" when it fails please? Marek also asked whether I have a broken network cable (n/a) or poor wifi (signal seems strong enough, i.e. no dropouts and problem occurs across different wifi networks), so it would be good to know that for you too. If you don't like github, happy to post any responses here into the ticket I have open. I've found a workaround (specified in the ticket) that fixes it for me, but interested to know if we're dealing with one problem, or different ones. Thanks. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/bumk34huiaO0hR8GdTU-HteBpeYDys3Z61RGy68KKgXkOb3lYT7BHoGQaxUxBVJERY52j6tsT42DVZEJAMo4nILhFK8HF5o7iegYzezsFo4%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes 3.2 Building an up to date dom0 3.18 Kernel
> Original Message > Subject: [qubes-users] Re: Qubes 3.2 Building an up to date dom0 3.18 Kernel > Local Time: August 21, 2017 2:38 PM > UTC Time: August 21, 2017 1:38 PM > From: r...@reginaldtiangha.com > To: qubes-users@googlegroups.com > > If you don"t trust me, you can easily do it yourself. Just clone the > master qubes-linux-kernel repo from the QubesOS account, change the > number in the "version" file to the latest number (as of now, it"s > 3.18.66 but you can verify that at kernel.org) and that"ll update what"s > already there. > > But some Xen security patches released since the last 3.18 version will > be missing and you"ll probably want to add those. Easiest way to do that > is to go here: > > https://xenbits.xen.org/xsa/ > > and grab any patches from there that have to do with the Kernel since > the last time a 3.18 release was pushed out and add them to your tree > (you can look at how Marek has applied them in the 4.9 branch; basically > you add the path to the patch into the series.conf file). Hint: It"s XSA > 157 (though not all five of them) and XSA 216. > > Finally, for bonus points, if you want a slightly harder kernel, you can > implement some of the KSPP recommended settings listed here (but not all > of them exist in 3.18 so you"ll need to search first): > > https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project > > and the Linux Hardened project here: > > https://github.com/copperhead/linux-hardened/wiki/Upstream-progress-tracking > > Those are basically the only changes I"ve made; in the 4.9+ kernel > configs, other changes have been for newer driver support that didn"t > exist in older versions. Good luck! Thanks for your time in replying Reg, something that interests me is the necessity of building in a FC23 VM. Would you agree there's a possibility of security issues whilst building as FC23 is EOL? (when fetching or verifying), not sure how Qubes builder gets around this, having tried in an up to date FC25 VM, it fails building the rpms despite dracut being up to date -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/BgtQzRK-xgZZQIpZDePIGRT0rY7-SmrYVrfLS5BCpJn1th96VSJcgi4B4Kbn-WUapQ6Rm8T8zNN0840ImLeJ-RFnM_RGj_9KQqo_8OfmX-Q%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Qubes 3.2 Building an up to date dom0 3.18 Kernel
As previously detailed ad nauseum, none of the Qubes dom0 4.4 or 4.9 version Kernels will boot on my laptop (HP Elitebook 2540p). This means I'm stuck on the ancient 3.18.17-8. I'm comfortable(ish - have built a Xenial template) using Qubes builder and I notice Reg Tiangha has a repo with updated 3.18 kernel at https://github.com/rtiangha/qubes-linux-kernel/ I notice Reg also submits patches which are merged into the official qubes-linux-kernel repo after review by Marek. 1. Is there any chance of getting the updated 3.18 kernel merged into the official repos so anyone (read me) with truculent hardware can remain on this, even if it means building the package ourselves? (this is actually what I was envisaging maybe happening when previously inquiring whether it was possible to buy a support case from ITL) 2. If not (not worth the effort of Marek to review?) given the existence of [https://github.com/rtiangha/qubes-linux-kernel](https://github.com/rtiangha/qubes-linux-kernel/) what are the suggestions to an 'ordinary' end user who wants to build a 3.18 kernel from there? Specifically, I'd be extending my trust from the Qubes developers to Reg, who apart from clearly being active in the Qubes community, I know nothing about. Are there sensible actions that can / should be taken with git to verify the kernel code? No insult to Reg here intended whatsoever :) Thanks -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/NoNPAoqjdRjpJ4aVcJXpaFMHKYJAWeRFLl6U98aj1bcPWbWnAMcCC9n-KpzknHplNV8yAk3Rn_Yq43IaYufwmViyWUF7Cg5La4jzZUye-SE%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Seeking moderators for unofficial Qubes IRC channels on Freenode and OFTC
> Qubes should not associate themselves with freenode or irc. That"s just my > opinion. Nobody with self respect or integrity has taken freenode serious for > over 10 years. It should stay unofficial. Not to knock what you're saying, but I think it's important for us to draw a distinction as a community between the infrastructure being potentially dangerous (which is the approach taken by ITL to the google list, the hosting services etc) with clear suggested mitigating actions for the end user to take (use GPG email, verify your ISO download etc) and the possibility that there are malicious individuals present on a medium wanting to do naive users harm (which seems on its face to be an argument towards moderating the IRC channels). Neither seem to be solved problems for IRC. We're in the difficult position of most other Linux distributions maintaining a freenode / IRC presence and advertising this [1] [2] [3] [4] [5] i.e. it's semi expected there will be some semi respectable community members idling. A very interesting point here is it's taken as a given that people understand that you should take advice on IRC at your own risk, and not explicitly stated anywhere by any of those distros. I don't think we should assume this is common knowledge for our user base, which I would argue is made up of very technically minded users, as well as users with other motivations (security, privacy) without much in the way of technical knowledge. Either camp may bowl up to the #qubes channel. If we think this is a bad idea™ I think we ought to clearly state so and why on the website. I can't immediately see on the website if anything is said of IRC, I thought the unofficial channel had been moved to OFTC for better tor support but I don't immediately see a mention of that. > I think google forums are a lot easier to use then installing some irc client > or connecting to a webchat, where the only people there are criminals or > spammers who want to exploit you or the network. Yes definitely easier, but a lot of people want to hang around and immerse themselves in community chat to learn, or to be part of that community. We shouldn't underestimate the number of people out there who outright hate the mailing list format, or even web forums. I do think live chat helps a community attract people who can be helpful to it. > Freenode and its communities are the sole reason Linux is unpopular. Be interested to know more about what you mean by this? > Its one of the most dangerous places to connect to, besides online games, > some porn sites, and darknet sites like silk road. I mean come on, it was > hilarious how it was portrayed on Mr. Robot, but they were not that far off. > Even though they brought back tor support, which is a catch22 for them, > (although you would need a special tor setup, standard setups dont" work) > Recommending people go to freenode is like leading sheeps to slaughter. Again we seem to be running up against the common knowledge problem. On my own (out dated) experience the risks associated with IRC were 1) the client being vulnerable to attack (shoutouts to mirc [6], xchat [7]) and 2) exposure of your internet facing IP address. Generally (showing my age) bouncers were used for the latter and I guess (not used IRC in 5 years) connection these days would be through whonix (who even on their wiki have a footer that says "bored? join us in IRC chat"). Where IRC seems to be a bad idea, is in the fact that you can't easily get a bouncer anonymously and IRC networks supporting TOR connections is a damned if you do and damned if you don't situation for them. My ultimate feelings (and the reason I've never joined a #qubes IRC channel to date) and why I sort of agree with you are summed up in https://phabricator.whonix.org/T361 which links to the associated Tor and Qubes tickets. Slack I've never used, but am put off by the fact it's proprietary. As a major factor in having an IRC channel is "users expect it because it's what other distros do" this raises the question do other distros have slack channels? I probably agree more with Jean-Philippe (when in Rome...) you mention Matrix, looks interesting, is there a good primer anywhere on how it solves the IRC problems discussed in the whonix and tor tickets? (yes, being lazy, sorry...) Disclaimer of interest = spent unhealthy proportion of teenage years running gaming IRC channels, suffering with bad case of nostalgia. [[1] https://wiki.ubuntu.com/IRC/ChannelList](https://wiki.ubuntu.com/IRC/ChannelList) [2] https://community.ubuntu.com/contribute/support/irc/ [3] https://help.ubuntu.com/community/InternetRelayChat [4] https://wiki.archlinux.org/index.php/IRC_channel [5] https://fedoraproject.org/wiki/How_to_use_IRC [6] https://www.cvedetails.com/vulnerability-list/vendor_id-189/product_id-325/Khaled-Mardam-bey-Mirc.html [7] https://www.cvedetails.com/vulnerability-list/vendor_id-552/Xchat.html -- You recei
Re: [qubes-users] Request for feedback: 4.9 Kernel
> Specifically, it'd be nice to know if: > 2) Hardware that didn't work with 4.4 or 4.8 still doesn't work. Having just tried 4.9.35-19, this has the same problem as every other 4.x kernel on my HP Elitebook 2540p (Intel HD graphics), that is as soon as the Qubes boot screen comes up, the graphics are corrupted. It was possible to enter the encryption password however the machine rebooted itself very soon after. Again this is consistent with every other 4.x kernel, either it reboots before the password prompt, or soon after. Only once has it ever got to the point of trying to start X. Is there anything useful I can provide given that the machine doesn't have a docking port or a serial port? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/9zFS1mqITeGtu-2v-gaYYitnt-gSLuVuYtlQz8ISwc33mKiu8Y_yCC4a1q5TsmuZZoxz4P3tdvCILWWl__XjZ_VWR436mki-ARMLSjT8DNU%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes silently ditches Librem
> Original Message > Subject: [qubes-users] Qubes silently ditches Librem > Local Time: July 8, 2017 8:24 AM > UTC Time: July 8, 2017 7:24 AM > From: bald...@tutanota.com > To: qubes-users@googlegroups.com > For those of us who followed Qubes hardware recommendations and then bought > or ordered shiny new Librem 13 laptops, you'll maybe not have noticed that > qubes has silently and sneakily withdrawn the recommendation leaving us all > in the lurch. > Originally qubes was sold to as all as a reasonably secure OS - that security > they said was built around the trusted ZEN platform. We now know that Zen has > numerous security vulnerabilities > How can we trust Qubes judgement anymore? I certainly don't. Okay, I'll bite because I have an interest in being involved with the documentation project and because I'm interested in getting a new Qubes laptop myself. Disclaimer that I don't read every post on the lists. I think certification here has been confused with recommendation, taking a quick look at history on github that seems to be the case. "-Some users may wish to consider [Qubes-certified laptops]. -However, it is important to note that such laptops are certified only for *compatibility* with Qubes OS. -In particular, the [Purism Librem 13] is certified only for compatibility with Qubes R3.x, and it is not likely to be certified for compatibility with Qubes R4.x. -Aside from compatibility, we do not believe that it should be considered any safer than other laptops." The original press release is more positive https://www.qubes-os.org/news/2015/12/09/purism-partnership/ but doesn't to me make any claims for the product beyond compatibility. This said, a reference to the previous arrangement (and what happened to it, it may just be that the contract for the cut for the developers from each sale expired) would be good to display on the page for the avoidance of this exact discussion. Purism have made their own statement here https://puri.sm/posts/2017-07-shipping-update-for-qubes-orders/ and it looks like they aren't producing the certified laptop anymore and don't want to pay for the new certification procedure. This is fine and their right best as I can see. I do find it odd that before this though they state they do not have an automated OEM image at present...I'd be curious to know if they've ever had one of those. >From a business / customer service point of view, I'm curious to know how you >feel left in the lurch, has a specific Qubes update bugged out on your >machine, or do you worry that ITL are aware of a more fundamental issue with >these laptops they're keeping close to their chests? (I'd think that unlikely, >as shit of that kind always floats to the surface given enough time). The new >requirements seem fairly pragmatic (i.e. coreboot and allowing some vendor >blobs) https://www.qubes-os.org/news/2016/07/21/new-hw-certification-for-q4/ I'd be interested to know what the charge purism refer to is, though I guess it's the time of ITLs week in poking the laptop to their satisfaction. On the "zen" point, I wonder if it's possible to interpret "reasonable secure" in two different ways. At one point on these lists a slogan for Qubes of "be your own bitch" was bandied about which I always felt much more appropriate, and the two always remind me of the definition of an optimist and a pessimist (i.e. "we're safe forever" vs "we're due"). Again, I don't think the developers have done anything underhanded here, yes they plumped for Xen as hypervisor in which serious vulnerabilities have been found but they both publish a record of the impact of these vulnerabilities https://www.qubes-os.org/security/xsa/and have provided a better backup recovery method https://www.qubes-os.org/news/2017/04/26/qubes-compromise-recovery/ for those who wish to proceed as if they have indeed been compromised after every such vulnerability comes to light. They've also been quite critical of the Xen project in the proceeding years and are changing the type of virtualisation used in Qubes 4.0, this leads me to believe that should they ever completely lose patience with Xen, they would move Qubes to a different Hypervisor (if a better one was available) and indeed the underlying framework allows this. Again, the question I'd be interested to ask if how this brings judgment into question? One of the criticisms I believe ITL / Qubes has made of Xen is that it is too focused on adding new features required by commercial users at the expense of security, but a different hypervisor would still need to be "better" enough to justify the work in moving to it... -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discu
Re: [qubes-users] Re: What do you think about Grsecurity future ?
> Original Message > Subject: [qubes-users] Re: What do you think about Grsecurity future ? > Local Time: July 5, 2017 6:05 PM > UTC Time: July 5, 2017 5:05 PM > From: turboa...@gmail.com > To: qubes-users > turboa...@gmail.com > End of official PaX and grsecurity support in Arch Linux > https://lists.archlinux.org/pipermail/arch-general/2017-April/043604.html It's a great pity, especially as the coldkernel guys were just starting to get going with something us Qubes users could deploy. I don't know any of the personalities involved to speak to the wider issues of whether the decision to pull public patches is justified or not, but personally if it's a big enough FU to large corporate rip off merchants of original work and causes them enough problems perhaps it's worth the aggravation to us mere mortals. If it's just about money and whose balls swing the longest...well meh. For some reason (given I don't use his OS or know him) I trust the word of the copperhead guy. I'm unsure of the impact (if any) on what benefits could have been bought to dom0 had the decision not been taken, but in VM terms, where we rely on qubes provided kernel or distro via pvgrub2 I guess it's business as usual. As I'm using 'their' OS, if ITL didn't deign to include something, I'm generally happy with that decision. Once action I have taken is to enable tasket's root action prompt [1] for my disposable VM template as a bit of 'hardening' there, although I can see Joanna spitting in my eye from here for supporting that action ;) In my view there is some utility in knowing if something opened in a dispvm is trying to escalate to root... [[1] https://www.qubes-os.org/doc/vm-sudo/](https://www.qubes-os.org/doc/vm-sudo/) -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/GhqN2g6YfjQkDuDFqUSRhvKaZWvLMhoCZGxiIvfoB0PPETuAjlqwYEFerys7E_ay8QxKPwnP5nmvWQUxptjCHoVRX0kUWZe928bhHqC1HX8%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Setting up regular bitcoin donation / buying support case?
Hi all Over on https://www.qubes-os.org/donate/ I see I can setup a donation one of two ways, Bitcoin and via Open Collective, however 14% for the latter seems a hell of a donation overhead. As such, I'd like to use Bitcoin but have no idea how. While I realise there are probably many idiots guides, I wonder if this is a common feeling of people that visit the donate page. I'm happy to muddle through setting up a recurring bitcoin donation and then contribute a guide (I currently have nothing else for which I would use bitcoin) if this would be helpful, but also wonder if someone has some notes stuffed away in a gist or similar somewhere? On a related point, I've not been keeping up on all the ways you guys are seeking funding, but I believe selling individual support licenses for those who wished to purchase them was decided to be not worth the revenue it would generate vs effort, is this still the case? I use Qubes as my daily driver and cannot get any of the 4.x series kernels to work on my laptop, so am behind on this element of security updates. I take it I can't purchase a support case from ITL at the current point in time? Vin -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/IqQb7fAEm5pfJp6bH03u69tcB0h4H3WgPzc0rqa11yXLOzNrHe0-NMtF91XGpGPqlcEmPTVq0jP5ixSuOd4atb9wfWV9mo5_kq_u1JX0gZs%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] HCL Elitebook 2540p / Complete inability to use any Qubes 3.2 4.x series kernel
The only kernel that still functions is the leftover 3.8.17-8 from 3.1. Which is working fine for now, are there any downsides to continuing to use this? Going by today's security bulletin[1], which releases a new kernel - it seems that there may well be downsides. I wonder how best to proceed, I take it no one else is in this situation? [1] https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-031-2017.txt -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/k7uot33w6f6GO4e0hQuvWsz0ntO7Cd-U-gN-2JoQfLCpCpJcaP5ZTe03G63DWs9W9XbqzbBF8lBEQBM8Xwhp5IZWzTzXgueqcaJ5Itg-44E%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Xen high CPU usage, but nothing is running in the VM
This happens to me sometimes on the current Xen/Linux versions. When I look at top in the offending VM its "kswapd" that has gone berserk. -- Chris Laprise, tas...@openmailbox.org https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- I can confirm I've also experienced this with kswapd in either sys-net or sys-firewall, can't remember which. Only way around it I found was to reboot the VM. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/iN97IVQYSzHL2rj-89YTu_69EELdKrifa-PH33Mz3dMgvfxsk6BXhyBqLXVDUPHLzdhbgTJZCJXuVmU91J7wVRVeIAfkg2wg2FrjSFIzq2Y%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] HCL Elitebook 2540p / Complete inability to use any Qubes 3.2 4.x series kernel
Hi all Having upgraded to 3.2 it's basically as I assumed, no 4.x series kernel will boot on my laptop, the graphics on the Qubes boot screen are completely corrupted and some of the kernels reboot a second or so after the Qubes boot screen appears. The only kernel that still functions is the leftover 3.8.17-8 from 3.1. Which is working fine for now, are there any downsides to continuing to use this? I suppose I need to mark it as protected so I can try new kernels as they are released, but ensure it is not removed... -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/iXqIIJtYyO82Qg_QBP0VB2P3_AwbTXWo84VJ7rJKr7A90xePuqIxlO7Mbb2bmpuQu-LbTUYfZcgppHKz5ScrdjTIsZvIqhwCdKn9fNPaDT4%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout. Qubes-HCL-Hewlett_Packard-HP_EliteBook_2540p-20170618-130131.yml Description: application/yaml
[qubes-users] 3.1 - 3.2 upgrade no qubes-upgrade-vm package available?
Hi all Following the upgrade instructions from 3.1 to 3.2, in the upgrade Fedora templates section the text talks about installing the qubes-upgrade-vm package, however this is not available in my Fedora 24 templates, is the section Fedora 23 specific? Thanks -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/nyw5cDYguU-AMFyrgWBXyJhQxJ_BedNlAP3QvP6uxPskJ3rsJG8ud-F35YvipVfyCDb_TyNih8Z-LZtDmjPq7mNdLL8pNwOvf1iAtLw4V9k%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Kernel issues preparing for 3.1 - 3.2 Upgrade
I've always had difficulties booting the default kernel of 3.1 (4.1.24.10), graphic corruption making it impossible to complete a boot. As such I've just always used 3.18.17-8 which behaves fine on my hardware. Am now preparing to make the upgrade to 3.2, but want to ensure if at all possible there is a kernel that will boot before I do. Is it possible / logical to test the same kernel version that will be available / default with 3.2 on 3.1 or is it much more a suck-it-and-see if it sucks sort of situation? Had some time to get back to looking at this. The issue is the same with any of the 4.x kernels in 3.1's unstable repo. Having tried various i915 kernel parameters without luck the only one that has an effect is plain old "nomodeset", which initially goes okay but then won't get as far as the login screen "failed to start graphics turbo". I don't think the driver actually works without kernel mode setting? Having read around a bit, I'm wondering if this is a consequence of the driver switching to SNA rather than UXA in Kernels 4 and up, however I don't see any way to set this as a kernel parameter, only in an X config file, but the issue here is not being able to get as far as the login screen. The only other thing that occurs, is that perhaps the 4 kernel will behave better with 3.2 having a more recent version of xorg-x11-drv-intel than 3.1 - I've really no idea how this package and the driver in the kernel interact... I'm going to have to just perform my backup and try the upgrade to 3.2, but not exactly enthused as to chances of success -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/uanJmjjzgERCUQ13Ke5rM7ivw-XtquEu1g-gGlEZBxtTUvw5VGZ7GI_pT_Xk1kb2guHdzuuJqmQmqG2mr-zwzVJsBjW3mJKBQuuzyli5UH8%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Kernel issues preparing for 3.1 - 3.2 Upgrade
I've always had difficulties booting the default kernel of 3.1 (4.1.24.10), graphic corruption making it impossible to complete a boot. As such I've just always used 3.18.17-8 which behaves fine on my hardware. Am now preparing to make the upgrade to 3.2, but want to ensure if at all possible there is a kernel that will boot before I do. Is it possible / logical to test the same kernel version that will be available / default with 3.2 on 3.1 or is it much more a suck-it-and-see if it sucks sort of situation? Thanks -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YJHiVcbFY3HLWGABu3YVLyZz-I_lF6Cgyzfh-1lfFSKA85vKz6Bovt_cxT0nn1pdUY0Tonm4Bj6tSNQJsJ5T-yQGKcwNB2PChBUqL33pEaQ%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Q3.1 fedora-24-minimal template - dom0 update problem
Oh. Or install yum in fedora24 template. Nvm then. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/itNy01G7fEK-bIChUc1ucqh0H3niON9JFO_3o4BiuVGmGyrhF4aNRiUe5P_Y1EvATAix_6tujs8KZ8KNOHJzvm-0UMPTY4TudzAaCub8jsQ%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Q3.1 fedora-24-minimal template - dom0 update problem
Hi all Having installed the necessary packages (at least per website doc) and assigned fedora-24-minimal to sys-firewall dom0 complains on update that yum / yumdownloader command cannot be found on the sys-firewall (which I guess is correct on fedora-24?). I guess Yum= should be dnf in qubes-download-dom0-updates.sh? Not really looked at how this works before Thanks in advance -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/z5f70DMyvO_7iiOGyRbeZsc2MnWwVN9pwGP4in7V78oPzEJDiTX4rKwW27od6SAIUQoMQDO_TPdgupjh7D8kJmHLaEBZ2xeI070f-i5lEGo%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] GUI Daemon error with new fedora-24-minimal template
It looks like template uploaded to 3.1 repository was built for Qubes 3.2, so this is why it's incompatible. I've just removed this faulty template, building new one - will be ready in few hours. - -- 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? Whoops. Thanks Marek. Will uninstall it and wait a bit then. Seems like I'm an oddball still using 3.1 and fedora-minimal if I'm the first to run into it! -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5wSXKApkkvtr1O2jze_vjxiwAVxsohfdnVVT4fq_ouBRskazEr5jQLuXeOy88oEsaoaZdogzVsURMTkGScdueAzkKZ6dSsgZpCrVtPaFB34%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] GUI Daemon error with new fedora-24-minimal template
Hi all Qubes 3.1 Have downloaded the new qubes-template- fedora-24-minimal however on starting it the following message is received "Dom0 GUI daemon do not support protocol version 1:1 requested by VM. To update Dom0..." etc Does the template require a version of gui currently only in testing repo? I'd have imagined yum would have warned me if so. Thanks -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/tgKwqYg1wmJsRQSeLyp7WSou_LhTLLCcyRCbzx_zQGOhmXa1-IDBAVKiKZeL8Ub4vAYgAdR5hQSXvzkpDnd8x1hUELQrFu8Brn-QrjD36mc%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] 3.0 to 3.1 in place upgrade broke USB VMs
Sounds like it could have been introduced in R3.1 Xen 4.6 for you specifically due to your hardware. If that's the case, it wouldn't be a good idea to note this on the page, since it might not apply to others. - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org Thanks Andrew. That's interesting, I'd assumed it was a binary proposition introduced in 4.6 having only briefly scanned http://www.gossamer-threads.com/lists/xen/devel/391684 If not I take your point however I still feel it should be referenced in some way on the upgrade instructions page to stop others potentially wasting the same time I did, and subsequently the lists time IF they run into it. If the issue does not apply to users hardware, user will simply have no problem with their existing device to VM assignments and proposed note is ignored. Without a note, if it does apply to their hardware they may (stupidly) like me read the existing FAQ entry and assume pci strictreset is not the problem as otherwise problem would have begun in R3.0... So perhaps it's the FAQ entry that needs clarifying? From a naive point of view, it makes sense that USB controllers might share some resources but on what appears to be "sensible" hardware that has one controller for USB ports and another for webcam etc it came as more of a surprise. Best Vince -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/W8EuHoowg8R0Mwna-xD0ZCop6Gz13WQMeHgP4eRJZmtJX7MJ7Nku2QqQhVUS32M30M426roQuxLZhuhvdIk9vjf-tNH9uSPbNnw9phZOhVk%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] 3.0 to 3.1 in place upgrade broke USB VMs
Apologies, this appears to be the shared RMRR problem discussed in https://github.com/QubesOS/qubes-issues/issues/1544 This is indeed in the FAQ, but I was thrown by the doc at https://www.qubes-os.org/doc/user-faq/#i-created-a-usbvm-and-assigned-usb-controllers-to-it-now-the-usbvm-wont-boot stating the problem began in R3.0, when by this experience it actually seems to have been introduced in R3.1 xen 4.6?. Pity as it was nice having USB ports and built-in USB devices in separate VMs. Although I guess it's for the best, as I was relying on the reset ability which apparently wasn't supported by the hardware... In any case, worth a note on https://www.qubes-os.org/doc/upgrade-to-r3.1/ page? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/UCo8aCugrJ2Dvbz2F9jSSsiPucHhdcY18TL_xnx9eWRDFfK-Mb-SDofD9P2WmC5KMhmyHTqEydjeEiZoF0PgUc5QrFDjCjYCkgr8m_Ie3kA%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] 3.0 to 3.1 in place upgrade broke USB VMs
The in place upgrade from 3.0 to 3.1 broke my two USB VMs (one controller with ports, one controller with devices) which were both set to auto start and working on 3.0. The error is similar to that where devices are assigned to another running VM - this is not the case however. livirt.libvirtError: Requested operation is not valid: PCI device xyz is in use by driver xenlight, domain usbvm sys-net still auto starts and everything else seems to work. Both VMs start fine without the USB devices assigned. I've tried hiding the devices from dom0 in case this made any difference using the kernel line in the docs, but this has made no difference. TIA -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ULyzjiM2Df5aepri0VxtxWHI2MoeVyJaqxvwKW3hJdBdKlHVpn5jeDbtZmsk0G69lRRdp-9vAoVpIID2ska-Pgn_pJ8DvJ0BzmrTV3I45sw%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.