So in case you haven't heard of it (or noticed about it), there was a
kerfuffle in Firefox land recently about this:
https://www.theverge.com/2017/12/16/16784628/mozilla-mr-robot-arg-plugin-fi…
As part of a tie-in with an American TV show, Mozilla thought it'd be a
great idea to silently install a cryptically-named addon in all(?)
Firefox deployments. Which can't be turned off.
This is concerning enough - a Random Internet Person quoted in the
article has a solid explanation as to why:
"There are several scary things about this:
- Unknown Mozilla developers can distribute addons to users without
their permission
- Mozilla developers can distribute addons to users without their
knowledge
- Mozilla developers themselves don't realise the consequences of doing
this
- Experiments are not explicitly enabled by users
- Opening the addons window reverts configuration changes which disable
experiments
- The only way to properly disable this requires fairly arcane
knowledge Firefox preferences (lockpref(), which I'd never heard of
until today)"
Mozilla's response is also, IMHO, rather worrying, because it seems to
fail entirely to grasp how concerning this kind of action is, and seems
concerned instead with self-justification and downplaying:
“Our goal with the custom experience we created with Mr. Robot was to
engage our users in a fun and unique way,” a Mozilla representative
said in a statement. “Real engagement also means listening to feedback.
And so while the web extension/add-on that was sent out to Firefox
users never collected any data, and had to be explicitly enabled by
users playing the game before it would affect any web content, we heard
from some of our users that the experience we created caused
confusion.”
(FWIW I don't think that statement is even factually correct; I can't
prove it with screenshots, but I'm pretty sure that when the addon
appeared in my Firefox install, it was enabled, not disabled).
I think we should be concerned by this kind of behaviour on the part of
the supplier of our default desktop browser, and we should express that
concern to them. Assuming Fedora-as-a-project shares my concern, do we
have a channel to communicate with them about this, and request
assurances that they understand the seriousness of this, and that they
have changed policies so that nothing like it will happen in future?
Thanks.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
Hi All,
As part of: https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife
I'm pushing a change to the Fedora Rawhide kernel to enable the new
med_power_with_dipm sata link powermanagement policy by default on
mobile Intel chipsets (Laptops, NuCs, etc.).
The good news about this change is that on laptops using a sata disk
it will typically save about 1W - 1.5W of power when the laptop is idle.
The bad news is that the min_power policy is known to cause data corruption
with some disks (has been reported with older sandisk ssds and some crucial
ssds). The new med_power_with_dipm sata lpm policy mirrors the default
Windows IRST lpm settings, so it should be safe to use, but the proof is
in the pudding.
I've done a blog post a while back asking users to test
this: https://hansdegoede.livejournal.com/18412.html and here is a list
of successfully tested systens + disks:
https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife#How_To_Test
So far no problems have been reported but if you're running rawhide now
would be a good time to make sure your backups are in order before
upgrading to the next rawhide kernel.
TL;DR: The next rawhide kernel build contains SATA changes which _may_
cause disk corruption, they shouldn't, but please check your backups
before updating.
Regards,
Hans
The primary logged-in session is of course authorized to access the main
X11/wayland display, but it's often useful to add display authorization
to other accounts. For instance, looking at disk space with 'baobab'
works better as root because some areas of the filesystem are not
readable to normal users (*). I used to do such authorization by
xhost +si:localhost:root
but it recently stopped working:
https://bugzilla.redhat.com/show_bug.cgi?id=1527754 . Is there another
way of authorizing display access for other accounts? If not, this is a
fairly painful regression.
As to the root cause, it almost looks like some unfinished work is being
done on API changes in the code for change_host() ; it prepares the
arguments for XAddHost() in a complex form, but the actual definitions
in the version of libX11 being used are more simplistic (see my second
BZ comment). Could someone familiar with X11 development take a look at
this?
(*) I know, I know, we should move to running apps as regular user and
just give them only the capabilities they really need, but that's where
we are for now.
Hi,
I am listed as "main admin" on
https://src.fedoraproject.org/rpms/python-keyring
I took over starting with EPEL7, though, so I don't have access to the el6
branch.
The error is:
$ git push
Total 0 (delta 0), reused 0 (delta 0)
remote: FATAL: W refs/heads/el6 rpms/python-keyring ctubbsii DENIED by
refs/heads/el[0-9]
remote: error: hook declined to update refs/heads/el6
To ssh://pkgs.fedoraproject.org/rpms/python-keyring
! [remote rejected] el6 -> el6 (hook declined)
error: failed to push some refs to 'ssh://
ctubbsii(a)pkgs.fedoraproject.org/rpms/python-keyring'
This is strange, because there does not seem to be any UI to request
changes.
I have a bug fix for a long-standing bug in el6. I've already patched in
epel7, but want to backport to el6 so I can close the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=924486
I tried to "Give" myself the project, but this only resulted in HTTP/500
error in Pagure. I can't give myself admin or commit, because I already
have it (for most branches).
Can somebody either grant me access, point me to where ACLs are now
managed, or just apply the patch according to my instructions in the
bugzilla ticket?
Thanks,
Christopher
When I built the new version of courier-unicode it broke cone, a cmdline
email client. I attempted to contact the owners before the change and
since with no response. I have no interest in being a maintainer of the
package so could someone with permissions merge this?
The latest upstream builds cleanly and appears to run in my light
testing. I've also added checking the gpg signature of the source.
Here's the PR:
https://src.fedoraproject.org/rpms/cone/pull-request/1
Thanks, and have a happy holiday!
--
Brian C. Lane (PST8PDT)