Re: Firefox "Looking Glass" fiasco

[Thomas Daede]

On 12/18/2017 03:00 PM, Sam Varshavchik wrote:
> Does anyone read this as Mozilla admitting that they messed up?

This was published today:
https://blog.mozilla.org/firefox/update-looking-glass-add/



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[Gerald B. Cox]

On Mon, Dec 18, 2017 at 3:00 PM, Sam Varshavchik 
wrote:

>
> Can you point out to me which part indicates that Mozilla admits that they
> made a mistake. Sounds to me like they're just blaming the dumb users for
> not understanding how wonderful was "the experience [they] created".
>

Keeping with the Mr. Robot motif, it is a riddle, wrapped in a mystery,
inside an enigma.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1527235] New: perl-App-Cme-1.026 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1527235

Bug ID: 1527235
   Summary: perl-App-Cme-1.026 is available
   Product: Fedora
   Version: rawhide
 Component: perl-App-Cme
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 1.026
Current version/release in rawhide: 1.025-1.fc28
URL: http://search.cpan.org/dist/App-Cme/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/9059/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 1016  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 778  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 360  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 258  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 255  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-7ecb12e378   
python-XStatic-jquery-ui-1.12.0.1-1.el7
  89  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23   
libmspack-0.6-0.1.alpha.el7
  27  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e64eeb6ece   
nagios-4.3.4-5.el7
  16  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d704442ae7   
qpid-cpp-1.37.0-1.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-97efaab7e7   
tor-0.2.9.14-1.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-f2055d3f62   
shellinabox-2.20-5.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-77cc9084cb   
nodejs-6.12.2-1.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-30026fdcc1   
hostapd-2.6-7.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d4de5890b2   
LibRaw-0.18.6-2.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-ae06399a6b   
heimdal-7.5.0-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-9a67291cf1   
json-c12-0.12.1-2.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

blueberry-1.1.20-1.el7
cinnamon-3.6.7-1.el7
composer-1.5.6-1.el7
duplicity-0.7.15-1.el7
nemo-3.6.5-1.el7
php-phpmyadmin-motranslator-3.4-1.el7

Details about builds:



 blueberry-1.1.20-1.el7 (FEDORA-EPEL-2017-124d4b3dc4)
 Bluetooth configuration tool

Update Information:

Update




 cinnamon-3.6.7-1.el7 (FEDORA-EPEL-2017-4b6145c8c6)
 Window management and application launching for GNOME

Update Information:

Update

References:

  [ 1 ] Bug #1465141 - Cinnamon menu - programs don't extend to bottom
https://bugzilla.redhat.com/show_bug.cgi?id=1465141
  [ 2 ] Bug #1514387 - [abrt] nemo: directory_ready_callback(): nemo-desktop 
killed by SIGABRT
https://bugzilla.redhat.com/show_bug.cgi?id=1514387
  [ 3 ] Bug #1512947 - [abrt] nemo: get_n_monitors(): nemo-desktop killed by 
SIGSEGV
https://bugzilla.redhat.com/show_bug.cgi?id=1512947




 composer-1.5.6-1.el7 (FEDORA-EPEL-2017-cc42e80571)
 Dependency Manager for PHP

Update Information:

**Version 1.5.6** - 2017-12-18* Fixed root package version guessed when a
tag is checked out   * Fixed support for GitLab reposhosted on non-standard
ports   * Fixed regression in require command when requiring unstable packages,
part 3




 duplicity-0.7.15-1.el7 (FEDORA-EPEL-2017-dfbc39ae13)
 Encrypted bandwidth-efficient backup using rsync algorithm

Update Information:

0.7.15

References:

  [ 1 ] Bug #1526724 - duplicity should be updated to version 0.7.15
https://bugzilla.redhat.com/show_bug.cgi?id=1526724




 nemo-3.6.5-1.el7 (FEDORA-EPEL-2017-4b6145c8c6)
 File manager for Cinnamon

Update Information:

Update

References:

  [ 1 ] Bug #1465141 - Cinnamon menu - programs don't extend to bottom
https://bugzilla.redhat.com/show_bug.cgi?id=1465141
  [ 2 ] Bug #1514387 - [abrt] nemo: directory_ready_callback(): nemo-desktop 
killed by SIGABRT
https://bugzilla.redhat.com/show_bug.cgi?id=1514387
  [ 3 ] Bug #1512947 - [abrt] nemo: get_n_monitors(): 

Re: Firefox "Looking Glass" fiasco

[Sam Varshavchik]

Gerald B. Cox writes:

Everyone makes mistakes - this wasn't the first by Mozilla and won't be the  
last.  I don't believe
they are acting out of malice.  As long as they admit and correct mistakes as  
they go along

that is fine with me.


Here's the most complete statement from Mozilla that I could find regarding  
this:




"Our goal with the custom experience we created with Mr. Robot was to engage  
our users in a fun and unique way," Mozilla's chief marketing officer,  
Jascha Kaykas-Wolff, told Gizmodo. "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."


"As a result we will be moving the Looking Glass Add-on to our Add-On store  
within the next 24 hours so Mr. Robot fans can continue to solve the puzzle  
and the source can be viewed in a public repository," Kaykas-Wolff added.




Can you point out to me which part indicates that Mozilla admits that  
they made a mistake. Sounds to me like they're just blaming the dumb users  
for not understanding how wonderful was "the experience [they] created".


Does anyone read this as Mozilla admitting that they messed up?



pgpaDMipRPWer.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1521155] _version_check gives unhelpful advice

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1521155



--- Comment #4 from Fedora Update System  ---
perl-Dancer2-0.204004-3.fc26 has been pushed to the Fedora 26 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-0dace90d48

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[Björn Persson]

Daniel P. Berrange wrote:
> IMHO requesting support for a build flag to disable this ability to
> remotely push executable code out to user's browser is not unreasonable,

I agree. There should be a single, properly documented build-time option to 
disable all current and future features that download and execute code without 
asking the user for explicit permission. If such an option doesn't exist, then 
I think the Fedora project should request one – and then use it. Any such 
feature should be strictly opt-in if it must exist at all (except for 
Javascript from the website being visited, because as much as I would like to 
make Javascript optional there's no chance of that happening at this point).

Björn Persson


signature.asc
Description: This is a digitally signed message part.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1526665] perl-PPI-XS-0.910 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1526665



--- Comment #5 from Fedora Update System  ---
perl-PPI-XS-0.910-1.fc26 has been pushed to the Fedora 26 testing repository.
If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-a19ecb8240

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[Björn Persson]

Chris Adams wrote:
> Are
> there any other packages that can silently download and run non-Fedora
> code?

The other web browsers. They'll silently download and run Javascript code from 
pretty much every website. It's a crazy dangerous practice, but that genie 
isn't going to go back into the bottle. But perhaps you meant "download and 
run without even trying to sandbox it"?

Björn Persson


signature.asc
Description: This is a digitally signed message part.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[nicolas . mailhot]

- Mail original -
De: "Adam Williamson" 

> My mail is based on a belief that Mozilla is still one of the better
> actors we have to work with in the category of desktop browser
> suppliers,

Adam, I agree it's still one of the better actors, but the better actor bar 
keeps lowering every year.

Mozilla has progressively redefined its "protect users of the internet" goal to 
"protect the communication between users and websites", and given how powerful 
javascript is nowadays that actually means "protect the right of websites to 
abuse users as they wish". They will lobby for any web standard extension 
pushed by cloud giants on the grounds it makes the internet better, without any 
thought for the effects of those extensions on protection of users from abusive 
websites.

Looking Glass is typical of this mindset: the server/cloud-side defines the 
rules, in that case server/cloud-side == Mozilla marketing, why should it 
constrain itself when it fights all year long to give the same power to any 
random website?

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1521155] _version_check gives unhelpful advice

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1521155

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Dancer2-0.205002-2.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-86379fd7f5

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1526665] perl-PPI-XS-0.910 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1526665

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-PPI-XS-0.910-1.fc27 has been pushed to the Fedora 27 testing repository.
If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-155263b957

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1524390] perl-Net-GitHub-0.91 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1524390

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-Net-GitHub-0.91-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-c2a9bfb129

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Fedocal] Reminder meeting : Modularity Office Hours

[nils]

Dear all,

You are kindly invited to the meeting:
   Modularity Office Hours on 2017-12-19 from 10:00:00 to 11:00:00 US/Eastern
   At https://meet.jit.si/fedora-modularity

The meeting will be about:
This is where you ask the Fedora Modularity Team questions (and we try to 
answer them)!

Join us on [IRC](irc://chat.freenode.net/#fedora-modularity): 
#fedora-modularity on [FreeNode](https://freenode.net)


Source: https://apps.fedoraproject.org/calendar/meeting/5910/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Bullet 2.87 coming to rawhide

[Rich Mattes]

On Tue, Nov 28, 2017 at 8:18 PM, Rich Mattes  wrote:
> Hi all,
>
> I'm planning on updating bullet to 2.87 in rawhide over the weekend.
> The following packages are affected:
>
> $ dnf repoquery --source --alldeps --whatrequires "bullet*"
> Last metadata expiration check: 0:37:51 ago on Tue 28 Nov 2017 07:31:59 PM 
> EST.
> bullet-2.83-6.fc27.src.rpm
> cyphesis-0.6.2-15.fc27.src.rpm
> efl-1.20.3-1.fc27.src.rpm
> efl-1.20.5-1.fc27.src.rpm
> fawkes-1.0.1-9.fc27.src.rpm
> gazebo-8.1.1-1.fc27.src.rpm
> openmw-0.41.0-7.fc27.src.rpm
> vdrift-20141020-10.fc27.src.rpm



With the exception of openmw, which is in rpmfusion, these builds are now done.

Rich
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[Björn Persson]

Florian Weimer wrote:
> On 12/18/2017 08:31 PM, Chris Murphy wrote:
> > I don't remember being actively asked about such data collection, and
> > I've recently installed on a clean system, nightly on Fedora, and then
> > final releases of 57 on Windows and macOS. Does anyone have a screen
> > shot or description of what this "ask" looks like, and when it
> > appears?
> 
> It keeps changing.  Currently, it's a pop-under tab shown once if you 
> open a new profile,

A background tab where the only visible words are "Firefox by default shares" 
does not match my understanding of what the word "ask" means.

And if I actually notice the tab and read the page, I don't see anything about 
silently installing additional software.

Björn Persson


signature.asc
Description: This is a digitally signed message part.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[Adam Williamson]

On Mon, 2017-12-18 at 22:36 +0100, nicolas.mail...@laposte.net wrote:
> Is it surprising that the Mozilla foundation, that decided long ago
> that users were idiots that didn't know what they wanted, and
> reoriented itself to serve the cloud industry

I don't share this opinion at all. If Fedora as a project does, then
the obvious course of action would be to find an alternative default
browser.

My mail is based on a belief that Mozilla is still one of the better
actors we have to work with in the category of desktop browser
suppliers, but that it's reasonable to believe that a message to them
from a relatively significant downstream along the lines of "hey,
folks, we kinda need you to demonstrate that you really understand why
this was a bad idea and be clear about how you plan to pull your socks
up" might have positive results.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[Björn Persson]

Adam Williamson wrote:
> since then, a new sub-preference seems to have appeared, labelled
> 'Allow Firefox to install and run studies'.

In the Swedish translation the sub-preference doesn't even exist. There is no 
second checkbox under the translation of "Allow Firefox to send technical and 
interaction data to Mozilla".

I was going to ask where this sub-preference was supposed to be as I couldn't 
find it. I restarted Firefox with "LANG=C firefox" to get the exact English 
wording of "Allow Firefox to send technical and interaction data to Mozilla", 
and only then did "Allow Firefox to install and run studies" appear. And it's 
turned on by default.

So now the question is: Do speakers of other languages have to periodically 
start Firefox in English mode and look for new misfeatures that they might 
want to opt out of, or are these so-called studies only inflicted on speakers 
of certain languages? Or did the option get turned on automatically now that I 
started Firefox in the C locale, and remains enabled henceforth unless I 
explicitly disable it?

Björn Persson


signature.asc
Description: This is a digitally signed message part.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[Gerald B. Cox]

On Mon, Dec 18, 2017 at 1:03 PM, Adam Williamson  wrote:

>
> Again, this is something I covered in my original mail. We distribute
> Firefox as the default browser to a large number of people who trust us
> to provide them with software. This gives us both a responsibility to
> our users and, presumably, some level of organized clout with Mozilla:
> I believe they will treat the concerns of the Fedora project with
> somewhat more interest than they would treat the concerns of...me.
>
> Raising it with upstream is exactly what I am suggesting, but I am
> suggesting that *the Fedora project* raises it with upstream. Not me.
>

If the Fedora project wants to do a "me too" that's fine - it's not going
to hurt anything - my point
was I believe they got the message loud and clear:

https://support.mozilla.org/en-US/questions/1194583#question-reply

and as you'll see, I was a bit blunt with them on the 13th:
"Folks this is really unacceptable. Reddit is losing their mind about it.
It's fine if this is associated with Shields studies - but you need use a
meaningful description - not some random quote that you think might be
cute.
It's not amusing to the millions of users who are thinking WTF."
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[nicolas . mailhot]

De: "Adam Williamson"
> 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.

Adam,

We should understand that there is a whole software ecosystem that grew on the 
Internet and free software, but emphatically does *not* share Fedora values.

For them free software is at best an absurdity and at worst an abomination, and 
open source is acceptable insofar it offers a ramp to open core or cloud 
services (which are really the same thing under different guises).

They are here to monetize users one way or another, will collect as much data 
as possible in the hope of selling it so someone, will make as much a PITA as 
possible the rebuilding of their software because free software that can only 
be rebuilt sanely by one org has all the properties of proprietary software 
without the associated user rejection. They will lobby for 'open source' and 
'bundling' and 'container images' because that reduces the actual chance their 
software can be industrialized by others (ie that severely reduces the SHARE 
property). Linux distributions in particular are their enemy both because they 
reduce the cost of deploying their software to zero, and have the capability to 
remove antifeatures at will.

Those people look closely at how Google managed to build android from open 
source bricks without letting it escape from its control and dearly wish to 
emulate that.

They are the same people that thought AIX and Solaris were crushing Linux, 
because their indicator was the amount of money paid for each system, not how 
useful it was for the society in general.

A few years ago their indicator switched to the number of users (when people 
were paying ridiculous amounts of money for websites based on their user 
count), now the indicator is moving to the amount of data that can be extracted 
from users (because big data and AI and get rich quick magic), next year it 
will be something else that will have no relationship with Fedora values.

Is it surprising that the Mozilla foundation, that decided long ago that users 
were idiots that didn't know what they wanted, and reoriented itself to serve 
the cloud industry, is increasingly sharing the values of this cloud industry, 
and only caring about user needs as defined by this industry? I'm sure the 
people that invented "looking glass" didn't realize (and do not realize today) 
there was any problem with it. I'm sure they are fuming at the injustice of 
getting hung high and dry when they were just doing business as usual as 
defined in those not-really-free-software circles.

This is only the first of many similar incidents, if we continue to think that 
any one professing "open source" is our friend. Many are not. Free software won 
the development story but free software values are no less marginal than a 
decade ago. Maybe even more so, now that the water is severely muddied.

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[Florian Weimer]

On 12/18/2017 09:59 PM, Gerald B. Cox wrote:

Everyone makes mistakes - this wasn't the first by Mozilla and won't be the
last.  I don't believe they are acting out of malice.


Of course not.  But at some level, there is a deception involved: 
Mozilla present a strong privacy focus for Firefox, but clearly lacks 
the processes to systematically prevent such blunders.


Of course, you can dismiss this as the usual tension between marketing 
and technical reality.  It's a bit like the reputation of Linux as a 
secure system vs the actual development procedures.


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[Adam Williamson]

On Mon, 2017-12-18 at 12:59 -0800, Gerald B. Cox wrote:
> On Mon, Dec 18, 2017 at 12:51 PM, Adam Williamson <
> adamw...@fedoraproject.org> wrote:
> 
> > 
> > > The only reason we are beating a dead horse is because you keep
> > > telling us that we shouldn't have beaten a dead horse in a way that
> > > requires us to explain why we are doing so. Look we understand.. you
> > > think we should all be friends again. Some of us however are on the
> > > "Play a trick on me once, shame on you.. Play a trick on me twice..
> > > shame on me" and this is number 3 or 4..
> > 
> > Right. As my original mail should have made clear to you but apparently
> > didn't, the point where I disagree with you is the idea that Mozilla
> > has "learnt its lesson". Nothing in any Mozilla statement I've seen so
> > far makes me believe that Mozilla has actually learned the right
> > lesson, and as Smooge points out, it is beginning to build up a track
> > record which makes me less willing to just trust that they have without
> > them explicitly stating it and outlining exactly what they have changed
> > in order to ensure that more things like this don't happen in future.
> > 
> 
> Everyone makes mistakes - this wasn't the first by Mozilla and won't be the
> last.  I don't believe
> they are acting out of malice.  As long as they admit and correct mistakes
> as they go along
> that is fine with me.  In any event, I don't believe this is a Fedora issue
> - it's an upstream issue.
> If you're unhappy with a particular direction or decision regarding Fx, it
> would be better to air those
> concerns upstream.

Again, this is something I covered in my original mail. We distribute
Firefox as the default browser to a large number of people who trust us
to provide them with software. This gives us both a responsibility to
our users and, presumably, some level of organized clout with Mozilla:
I believe they will treat the concerns of the Fedora project with
somewhat more interest than they would treat the concerns of...me.

Raising it with upstream is exactly what I am suggesting, but I am
suggesting that *the Fedora project* raises it with upstream. Not me.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[Gerald B. Cox]

On Mon, Dec 18, 2017 at 12:51 PM, Adam Williamson <
adamw...@fedoraproject.org> wrote:

>
> > The only reason we are beating a dead horse is because you keep
> > telling us that we shouldn't have beaten a dead horse in a way that
> > requires us to explain why we are doing so. Look we understand.. you
> > think we should all be friends again. Some of us however are on the
> > "Play a trick on me once, shame on you.. Play a trick on me twice..
> > shame on me" and this is number 3 or 4..
>
> Right. As my original mail should have made clear to you but apparently
> didn't, the point where I disagree with you is the idea that Mozilla
> has "learnt its lesson". Nothing in any Mozilla statement I've seen so
> far makes me believe that Mozilla has actually learned the right
> lesson, and as Smooge points out, it is beginning to build up a track
> record which makes me less willing to just trust that they have without
> them explicitly stating it and outlining exactly what they have changed
> in order to ensure that more things like this don't happen in future.
>

Everyone makes mistakes - this wasn't the first by Mozilla and won't be the
last.  I don't believe
they are acting out of malice.  As long as they admit and correct mistakes
as they go along
that is fine with me.  In any event, I don't believe this is a Fedora issue
- it's an upstream issue.
If you're unhappy with a particular direction or decision regarding Fx, it
would be better to air those
concerns upstream.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[Adam Williamson]

On Mon, 2017-12-18 at 15:48 -0500, Stephen John Smoogen wrote:
> On 18 December 2017 at 15:42, Gerald B. Cox  wrote:
> 
> > > And in any case, a tie-in with a television-show related game is
> > > clearly neither telemetry nor some kind of user interaction study. Yet
> > > to me, Mozilla's response does not seem to convey understanding of this
> > > at all. It basically just says "oh don't worry it didn't do anything by
> > > default", which is sort of grandly missing the point.
> > > 
> > 
> > Mozilla has already admitted they made a mistake and removed Looking Glass
> > from the
> > Fx Studies.  I believe they understand the situation quite well.  It's not
> > helpful to beat
> > a dead horse.
> > 
> 
> The only reason we are beating a dead horse is because you keep
> telling us that we shouldn't have beaten a dead horse in a way that
> requires us to explain why we are doing so. Look we understand.. you
> think we should all be friends again. Some of us however are on the
> "Play a trick on me once, shame on you.. Play a trick on me twice..
> shame on me" and this is number 3 or 4..

Right. As my original mail should have made clear to you but apparently
didn't, the point where I disagree with you is the idea that Mozilla
has "learnt its lesson". Nothing in any Mozilla statement I've seen so
far makes me believe that Mozilla has actually learned the right
lesson, and as Smooge points out, it is beginning to build up a track
record which makes me less willing to just trust that they have without
them explicitly stating it and outlining exactly what they have changed
in order to ensure that more things like this don't happen in future.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[Stephen John Smoogen]

On 18 December 2017 at 15:42, Gerald B. Cox  wrote:

>> And in any case, a tie-in with a television-show related game is
>> clearly neither telemetry nor some kind of user interaction study. Yet
>> to me, Mozilla's response does not seem to convey understanding of this
>> at all. It basically just says "oh don't worry it didn't do anything by
>> default", which is sort of grandly missing the point.
>>
> Mozilla has already admitted they made a mistake and removed Looking Glass
> from the
> Fx Studies.  I believe they understand the situation quite well.  It's not
> helpful to beat
> a dead horse.
>

The only reason we are beating a dead horse is because you keep
telling us that we shouldn't have beaten a dead horse in a way that
requires us to explain why we are doing so. Look we understand.. you
think we should all be friends again. Some of us however are on the
"Play a trick on me once, shame on you.. Play a trick on me twice..
shame on me" and this is number 3 or 4..


> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[R P Herrold]

On Mon, 18 Dec 2017, Chris Adams wrote:

> the requires downloads to be useful.  I think simply requiring Mozilla
> to change their policies is unacceptable, as this still depends on a
> third party to properly enforce such policies (and not have any security
> issue that could result in untrusted addons being installed).
> 
> IMHO such behavior needs to be disabled by default in any packages
> shipped by Fedora for Fedora to remain a trustworthy distribution.

'Electrolysis' was a Mozilla.org codeword for a sub-project 
enabling in an A:B sample, 'telemetry' -- that is keystroke 
logging, click monitoring, timing, and more, largely without 
prominent external notice.

I had a performance issue related to inter-tab communication 
in a restrictive environment I run Firefox in, along with 
SElinux denials, and spent some time 'running down' several 
problems, in the early summer

see:

https://support.ant.com/hc/en-us/articles/115000513446-Firefox-51-Multi-Process

see my bug: 
https://bugzilla.redhat.com/show_bug.cgi?id=1473754
upstream as well

https://bugzilla.mozilla.org/show_bug.cgi?id=1383141
closed into:

https://bugzilla.mozilla.org/show_bug.cgi?id=1376559



https://bugzilla.mozilla.org/show_bug.cgi?id=1129492

because SysV shared memory follows Unix's “same uid policy” 
and can't be restricted/brokered like file access.  (It was 
observed when the initial attempt at a desktop content system 
call whitelist was made, but that was long enough ago that 
there could have been significant changes to how graphics work 
that might make this not a problem, so this should be 
double-checked.)  There's a not-well-specified revision to use 
memory-mapped files 
(http://patchwork.freedesktop.org/patch/15082/) but I don't 
know what would need to happen to make it work — Ubuntu 14.04 
has a new enough X server and should (I think?) have new 
enough libraries, but X clients still empirically use SysV 
(including the Firefox parent process).


see also this:

https://mjg59.dreamwidth.org/42320.html

which implies a shm IPC privacy approach exists, but is not 
implemented.  It ignores adding SELinux constexts, and so the 
unhopeful conculsion he draws may have been overtaken by 
events


https://bugzilla.redhat.com/show_bug.cgi?id=1188290#c1

There was a related SELinux / no '--no-xshm IPC' filing 
upstream as well, which I cannot lay hands upon atm.  It looks 
like others have noticed the 100 pct usage, and IPC problems 
as well

https://bugzilla.redhat.com/show_bug.cgi?id=1471149


One had to notice such exfiltration of data, and go looking 
for how to turn it off.  I did by watching squid logs of 
queries, seeing expected domains, and then going looking.  

Adding a
prefs.js

with

//
browser.tabs.remote.autostart = false  
browser.tabs.remote.autostart.2 = false
//
// ... above silently set itself true again  2017 08 29
//  52.2.0 (64-bit) ESR
//  Centos 7, 2017 09 update is: 52.3.0 (64-bit)

was supposed to work, but it turned out that some process 
inside FF was able to over-ride and un-restrict such even when 
explicitly turned on.  I had to change ownershop of the 
configuration file to root.root from userid.blah to stop that 
nonesense


I start ff inside a 'ssh to a unpriv'd uid' localhost X  
forwarding tunnel -- it breaks sound and video, but ... *
shrug *   I'd rather not have data I care about being
exfiltrated


I believe Jan Horak inside RH does something similar

https://bugzilla.mozilla.org/show_bug.cgi?id=1129492

'it looks like the Firefox over ssh is not used by masses'


-- Russ herrold

===

PEFF -- Privacy Enhanced Firefox invocation 
 ... privacy enhanced, isolated userid firefox invocation 
 
startup PATH: 
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/home/herrold/bin
reduced path PATH: 
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/home/herrold/bin
current id: uid=500(herrold) gid=500(herrold) 
groups=500(herrold),10(wheel),135(mock),498(pulse-access) 
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
PEFF: ghola
note: ghola is a non-priv'd user on localhost, [H/T: Frank 
Herbert] 
  which we access via a keyed SSH connection 
  to try to avoid some content exfiltration by 
  hostile web browser applications: Firefox, Flash, etc 
THISHOST: centos-7.first.owlriver.net
start: Mon Dec 18 09:45:31 EST 2017
Command: ssh -X  -4   -l ghola centos-7.first.owlriver.net  
export ` dbus-launch ` ;   firefox  --no-remote   --  
 
now down in the limited, privacy enhanced firefox userid 
reduced path PATH: 
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/home/ghola/bin
current id: uid=606(ghola) gid=606(ghola) 
groups=606(ghola),498(pulse-access) 
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
Command: umask 022 ; /usr/bin/firefox  --no-remote   --  
___
devel mailing list -- 

Re: Firefox "Looking Glass" fiasco

[Gerald B. Cox]

On Mon, Dec 18, 2017 at 12:23 PM, Adam Williamson <
adamw...@fedoraproject.org> wrote:

> On Mon, 2017-12-18 at 20:52 +0100, Florian Weimer wrote:
> 
>
> So I just booted Firefox 27 Workstation live and opened Firefox.
> Indeed, a pop-under tab appears with this URL (so you can close it
> without even seeing it).
>

If you're concerned about security and privacy, you have to read.  It's not
fair to cast aspersions
because you weren't paying attention.

The relevant text reads:
>
> 
>
> I would suggest that nothing in this text reasonably covers "shield
> studies"; it was clearly written to cover old-school telemetry, not
> this later and more extensive capability to install custom-written add-
> ons to perform additional data collection. Yet the "Allow Firefox to
> install and run studies" checkbox is checked by default.
>

If you read the page, you'll see where there is a highlighted phrase that
says:
"Choose how you want to share this data in Firefox" following by a
selection button.
You are then taken to a page where you can opt-out and read more about the
Fx Studies.

>
> And in any case, a tie-in with a television-show related game is
> clearly neither telemetry nor some kind of user interaction study. Yet
> to me, Mozilla's response does not seem to convey understanding of this
> at all. It basically just says "oh don't worry it didn't do anything by
> default", which is sort of grandly missing the point.
>
> Mozilla has already admitted they made a mistake and removed Looking Glass
from the
Fx Studies.  I believe they understand the situation quite well.  It's not
helpful to beat
a dead horse.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[Adam Williamson]

On Mon, 2017-12-18 at 20:52 +0100, Florian Weimer wrote:
> On 12/18/2017 08:31 PM, Chris Murphy wrote:
> > I don't remember being actively asked about such data collection, and
> > I've recently installed on a clean system, nightly on Fedora, and then
> > final releases of 57 on Windows and macOS. Does anyone have a screen
> > shot or description of what this "ask" looks like, and when it
> > appears?
> 
> It keeps changing.  Currently, it's a pop-under tab shown once if you 
> open a new profile, using this URL:
> 
> 

So I just booted Firefox 27 Workstation live and opened Firefox.
Indeed, a pop-under tab appears with this URL (so you can close it
without even seeing it). The relevant text reads:

"Firefox by default shares data to:
Improve performance and stability for users everywhere

Interaction data: Firefox sends data about your interactions with
Firefox to us (such as number of open tabs and windows; number of
webpages visited; number and type of installed Firefox Add-ons; and
session length) and Firefox features offered by Mozilla or our partners
(such as interaction with Firefox search features and search partner
referrals).

Technical data: Firefox sends data about your Firefox version and
language; device operating system and hardware configuration; memory,
basic information about crashes and errors; outcome of automated
processes like updates, safebrowsing, and activation to us. When
Firefox sends data to us, your IP address is temporarily collected as
part of our server logs."

I would suggest that nothing in this text reasonably covers "shield
studies"; it was clearly written to cover old-school telemetry, not
this later and more extensive capability to install custom-written add-
ons to perform additional data collection. Yet the "Allow Firefox to
install and run studies" checkbox is checked by default.

And in any case, a tie-in with a television-show related game is
clearly neither telemetry nor some kind of user interaction study. Yet
to me, Mozilla's response does not seem to convey understanding of this
at all. It basically just says "oh don't worry it didn't do anything by
default", which is sort of grandly missing the point.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[Gerald B. Cox]

On Mon, Dec 18, 2017 at 12:06 PM, Chris Adams  wrote:

> Once upon a time, Gerald B. Cox  said:
> > First of all, when you install Fx, it asks you specifically if you want
> to
> > participate in Fx Data Collection - you can opt out at that point.
>
> AFAIK, not when you install from an RPM.
>
> See the reply from Florian Weimer - he did a good job in explaining it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[Chris Adams]

Once upon a time, Gerald B. Cox  said:
> First of all, when you install Fx, it asks you specifically if you want to
> participate in Fx Data Collection - you can opt out at that point.

AFAIK, not when you install from an RPM.

-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[Florian Weimer]

On 12/18/2017 08:31 PM, Chris Murphy wrote:

I don't remember being actively asked about such data collection, and
I've recently installed on a clean system, nightly on Fedora, and then
final releases of 57 on Windows and macOS. Does anyone have a screen
shot or description of what this "ask" looks like, and when it
appears?


It keeps changing.  Currently, it's a pop-under tab shown once if you 
open a new profile, using this URL:




You can run “firefox -P” and create a new profile if you want to play 
with this.  So far, there seems to be little cross-talk between those 
profiles, if there is any at all.


I found another odd thing: about:home network traffic is no longer 
logged by the web developer console. 8-(


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[Chris Murphy]

On Mon, Dec 18, 2017 at 12:16 PM, Adam Williamson
 wrote:
> On Mon, 2017-12-18 at 11:09 -0800, Gerald B. Cox wrote:
>>
>> First of all, when you install Fx, it asks you specifically if you want to
>> participate in Fx Data Collection - you can opt out at that point.
>
> Well, not quite. I installed Firefox rather a long time ago on this
> system. Again I can't prove it, but at that time I believe this
> question and preference referred *only* to 'data collection'. However,
> since then, a new sub-preference seems to have appeared, labelled
> 'Allow Firefox to install and run studies'. It appears, so far as I can
> tell, that they are claiming this promotional tie-in constituted a
> "study". That's a weak claim to start with, but more importantly, I am
> fairly sure this "Allow Firefox to install and run studies" preference
> was simply set to 'true' when it was *added* to Firefox. I was not
> asked. If I had been, I'm pretty sure I would've said no.

I don't remember being actively asked about such data collection, and
I've recently installed on a clean system, nightly on Fedora, and then
final releases of 57 on Windows and macOS. Does anyone have a screen
shot or description of what this "ask" looks like, and when it
appears?

-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[Gerald B. Cox]

On Mon, Dec 18, 2017 at 11:16 AM, Adam Williamson <
adamw...@fedoraproject.org> wrote:

> On Mon, 2017-12-18 at 11:09 -0800, Gerald B. Cox wrote:
> >
> > First of all, when you install Fx, it asks you specifically if you want
> to
> > participate in Fx Data Collection - you can opt out at that point.
>
> Well, not quite. I installed Firefox rather a long time ago on this
> system. Again I can't prove it, but at that time I believe this
> question and preference referred *only* to 'data collection'. However,
> since then, a new sub-preference seems to have appeared, labelled
> 'Allow Firefox to install and run studies'. It appears, so far as I can
> tell, that they are claiming this promotional tie-in constituted a
> "study". That's a weak claim to start with, but more importantly, I am
> fairly sure this "Allow Firefox to install and run studies" preference
> was simply set to 'true' when it was *added* to Firefox. I was not
> asked. If I had been, I'm pretty sure I would've said no.
>

You are correct that it is a sub-preference - and IF you allowed data
collection it was also allowed - because it
is in the same category.  As far as Looking Glass - they made a mistake,
and they admitted they made a mistake,
and have removed Looking Glass from studies

Personally, I have no issue with the shield studies and this episode didn't
cause me to opt out.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[Adam Williamson]

On Mon, 2017-12-18 at 11:09 -0800, Gerald B. Cox wrote:
> 
> First of all, when you install Fx, it asks you specifically if you want to
> participate in Fx Data Collection - you can opt out at that point.

Well, not quite. I installed Firefox rather a long time ago on this
system. Again I can't prove it, but at that time I believe this
question and preference referred *only* to 'data collection'. However,
since then, a new sub-preference seems to have appeared, labelled
'Allow Firefox to install and run studies'. It appears, so far as I can
tell, that they are claiming this promotional tie-in constituted a
"study". That's a weak claim to start with, but more importantly, I am
fairly sure this "Allow Firefox to install and run studies" preference
was simply set to 'true' when it was *added* to Firefox. I was not
asked. If I had been, I'm pretty sure I would've said no.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[Gerald B. Cox]

On Mon, Dec 18, 2017 at 10:36 AM, Kevin Fenzi  wrote:

>
>
> Additionally, can we turn the "Allow firefox to install and run studies"
> preference to off/false by default in Fedora packages. It seems odd that
> this is now opt-out.
>
>
I don't know.  I personally tend to side with upstream on their decisions -
and I don't believe Mozilla is acting in bad faith.

First of all, when you install Fx, it asks you specifically if you want to
participate in Fx Data Collection - you can opt out at that point.
If you change your mind later, you can go into preferences and security and
either disable or enable it.

It was quickly and forcefully pointed out to Mozilla that the automatic
installation of a game was something that most considered part
of that category.  They have since removed it.

Yes, it was a poor decision - but it has been corrected and hopefully they
learned their lesson.  Everyone needs to just move on.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[Daniel P. Berrange]

On Mon, Dec 18, 2017 at 10:42:17AM -0800, Adam Williamson wrote:
> On Mon, 2017-12-18 at 12:34 -0600, Chris Adams wrote:
> > Once upon a time, Adam Williamson  said:
> > > 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.
> > 
> > I thought that this was actually a violation of the packaging policies,
> > but I can't seem to find it now; I only see the restriction on software
> > the requires downloads to be useful.
> 
> IIRC there used to be a stricter policy that was relaxed as it had
> become kinda untenable with the widespread acceptance of addons and
> extensions for things like browsers and desktops. I could be wrong,
> though.
> 
> >   I think simply requiring Mozilla
> > to change their policies is unacceptable, as this still depends on a
> > third party to properly enforce such policies (and not have any security
> > issue that could result in untrusted addons being installed).
> 
> Well, practically speaking we do have to have *some* degree of trust in
> our suppliers for apps as large and complex as a web browser or, say,
> an office app. Let's face it, practically speaking we're not really
> equipped to handle an adversarial relationship there. Even if we say
> "we're going to patch out this mechanism", that only really works if we
> trust the vendor at least to the degree that we don't believe they'd
> insert a harder-to-detect back channel to do the same thing, because
> practically speaking we just don't have the resources to audit the
> entire Firefox codebase (or even audit changes from some point in time
> we consider 'trustworthy' onwards) to ensure they haven't done this.

IMHO requesting support for a build flag to disable this ability to
remotely push executable code out to user's browser is not unreasonable,
and shouldn't make Fedora seem "adversarial", unless there's bigger
trust issues at play here.

> > IMHO such behavior needs to be disabled by default in any packages
> > shipped by Fedora for Fedora to remain a trustworthy distribution.  Are
> > there any other packages that can silently download and run non-Fedora
> > code?
> 
> I dunno about 'silently', but there are certainly other cases of this,
> yes. GNOME Software can install GNOME Shell extensions (which are code,
> and can do anything with the privileges of the user account running the
> shell) from a non-Fedora source (extensions.gnome.org), for instance.

It won't install random new extensions without the user having asked for
them. At most it would update previously installed extensions to newer
versions. Though if someone did compromise the GNOME extensions service,
that distinction is fairly academic from a security POV. IOW, a security
concious person would not want to allow an communication to the
extensions.gnome.org service at all to protect themselves.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[Daniel P. Berrange]

On Mon, Dec 18, 2017 at 12:34:46PM -0600, Chris Adams wrote:
> Once upon a time, Adam Williamson  said:
> > 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.
> 
> I thought that this was actually a violation of the packaging policies,
> but I can't seem to find it now; I only see the restriction on software
> the requires downloads to be useful.  I think simply requiring Mozilla
> to change their policies is unacceptable, as this still depends on a
> third party to properly enforce such policies (and not have any security
> issue that could result in untrusted addons being installed).
>
> IMHO such behavior needs to be disabled by default in any packages
> shipped by Fedora for Fedora to remain a trustworthy distribution.  Are
> there any other packages that can silently download and run non-Fedora
> code?

It was brought up elsewhere that Chrome/Chromium in the past has done
something worse in scope, silently downloading an add-on to that turns
on & listens to your microphone. Ostensibly to detect the "ok google"
keyword, but since its a closed source add-on can you be sure that's all
it does...

 
https://www.privateinternetaccess.com/blog/2015/06/google-chrome-listening-in-to-your-room-shows-the-importance-of-privacy-defense-in-depth/

Fortunately, the Fedora builds of Chromium have explicitly disabled this
feature (enable_hotwording=false in chromium.spec)

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[Chris Adams]

Once upon a time, Adam Williamson  said:
> Well, practically speaking we do have to have *some* degree of trust in
> our suppliers for apps as large and complex as a web browser or, say,
> an office app.

True, but I do think there's a difference between trusting code we get
and trusting that they will properly secure/won't abuse an additional
install channel.

> I dunno about 'silently', but there are certainly other cases of this,
> yes. GNOME Software can install GNOME Shell extensions (which are code,
> and can do anything with the privileges of the user account running the
> shell) from a non-Fedora source (extensions.gnome.org), for instance.

So, I guess it is in policy somewhere, but... what's the difference
between that and Fedora having RPMs that install yum repo files for
other repositories?
-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1504429] perl-Term-Table-0.012 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1504429



--- Comment #3 from Fedora Update System  ---
perl-Term-Table-0.012-1.fc27 has been pushed to the Fedora 27 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[Adam Williamson]

On Mon, 2017-12-18 at 12:34 -0600, Chris Adams wrote:
> Once upon a time, Adam Williamson  said:
> > 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.
> 
> I thought that this was actually a violation of the packaging policies,
> but I can't seem to find it now; I only see the restriction on software
> the requires downloads to be useful.

IIRC there used to be a stricter policy that was relaxed as it had
become kinda untenable with the widespread acceptance of addons and
extensions for things like browsers and desktops. I could be wrong,
though.

>   I think simply requiring Mozilla
> to change their policies is unacceptable, as this still depends on a
> third party to properly enforce such policies (and not have any security
> issue that could result in untrusted addons being installed).

Well, practically speaking we do have to have *some* degree of trust in
our suppliers for apps as large and complex as a web browser or, say,
an office app. Let's face it, practically speaking we're not really
equipped to handle an adversarial relationship there. Even if we say
"we're going to patch out this mechanism", that only really works if we
trust the vendor at least to the degree that we don't believe they'd
insert a harder-to-detect back channel to do the same thing, because
practically speaking we just don't have the resources to audit the
entire Firefox codebase (or even audit changes from some point in time
we consider 'trustworthy' onwards) to ensure they haven't done this.

> IMHO such behavior needs to be disabled by default in any packages
> shipped by Fedora for Fedora to remain a trustworthy distribution.  Are
> there any other packages that can silently download and run non-Fedora
> code?

I dunno about 'silently', but there are certainly other cases of this,
yes. GNOME Software can install GNOME Shell extensions (which are code,
and can do anything with the privileges of the user account running the
shell) from a non-Fedora source (extensions.gnome.org), for instance.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[Florian Weimer]

On 12/18/2017 07:29 PM, Adam Williamson wrote:

Sure. A new release coming out affords many people in the pipeline many
chances to notice changes in it. The packager has the opportunity to
notice significant changes while updating the package. Users of
updates-testing have the opportunity to notice any significant changes
before the update goes out to the broader user base. And users, unless
they have manually set up some sort of non-notifying automated update
script, either make a conscious choice to install the update or are at
least notified that it has taken place, both of which provide them with
the opportunity to examine changes and decide if they wish to accept
them.

Silently deploying an addon to existing installations of Firefox
bypasses absolutely all of the above.


On the other hand, when it comes to privacy settings, if Firefox 
developers make changes to the settings themselves (not their defaults, 
but how they are encoded in profiles), they usually do not make an 
attempt to inform the user or preserve the intent as closely as 
possible.  Two examples come to my mind:


When the “Ask me every time” cookie setting was abolished, it was 
silently changed to “Keep [them] until they expire”, so people were now 
tracked without their consent, until they realized what had happened.


When the New tab page was redesigned, major redesigns discard previous 
settings to offer a blank page and not to capture thumbnails.


In either case, I wasn't aware of proper communication.  With the 
complexity of the code base and the widespread use of extensions, there 
is little anything any downstream can do.  (This is also the reason why 
I'm wary of privacy-enhanced downstreams because they surely can remove 
only the obvious stuff.)


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[Kevin Fenzi]

On 12/18/2017 09:55 AM, Adam Williamson wrote:
...snip...
> 
> “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 even when the extension was 'enabled' you had to do something
further to cause it to do anything. But it's not very clear...

> 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?

That would be good (I don't know if we have such a channel or not).

Additionally, can we turn the "Allow firefox to install and run studies"
preference to off/false by default in Fedora packages. It seems odd that
this is now opt-out.

kevin




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[Chris Adams]

Once upon a time, Adam Williamson  said:
> 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.

I thought that this was actually a violation of the packaging policies,
but I can't seem to find it now; I only see the restriction on software
the requires downloads to be useful.  I think simply requiring Mozilla
to change their policies is unacceptable, as this still depends on a
third party to properly enforce such policies (and not have any security
issue that could result in untrusted addons being installed).

IMHO such behavior needs to be disabled by default in any packages
shipped by Fedora for Fedora to remain a trustworthy distribution.  Are
there any other packages that can silently download and run non-Fedora
code?

-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[Adam Williamson]

On Mon, 2017-12-18 at 13:08 -0500, Matthew Miller wrote:
> On Mon, Dec 18, 2017 at 09:55:26AM -0800, Adam Williamson wrote:
> > 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?
> 
> Is there a fundamental difference between this and, if, say, similar
> functionality were in the FF 57 release itself?

Sure. A new release coming out affords many people in the pipeline many
chances to notice changes in it. The packager has the opportunity to
notice significant changes while updating the package. Users of
updates-testing have the opportunity to notice any significant changes
before the update goes out to the broader user base. And users, unless
they have manually set up some sort of non-notifying automated update
script, either make a conscious choice to install the update or are at
least notified that it has taken place, both of which provide them with
the opportunity to examine changes and decide if they wish to accept
them.

Silently deploying an addon to existing installations of Firefox
bypasses absolutely all of the above.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[Stephen John Smoogen]

On 18 December 2017 at 13:08, Matthew Miller  wrote:
> On Mon, Dec 18, 2017 at 09:55:26AM -0800, Adam Williamson wrote:
>> 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?
>
> Is there a fundamental difference between this and, if, say, similar
> functionality were in the FF 57 release itself?
>
>

I am not sure I understand your question enough to formulate what
difference you are wanting. Since the addon was distributed POST
install without user intervention, it would seem yes there is a big
difference. If it were installed in FF57 then I wouldn't
install/update to that version. If it is 'pushed' post install then it
means that just using the software means that Mozilla can push addons
to my desktop without my intervention or knowledge. This takes the
browser from being my software to always being 'their' software which
I am just using for their pleasure.

It also brings up questions of what value add does Fedora have in
actually distributing it if we can't 'stop' them from doing so.


>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[Matthew Miller]

On Mon, Dec 18, 2017 at 09:55:26AM -0800, Adam Williamson wrote:
> 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?

Is there a fundamental difference between this and, if, say, similar
functionality were in the FF 57 release itself?



-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Firefox "Looking Glass" fiasco

[Adam Williamson]

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-firefox-looking-glass

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: MASS CHANGE announcement: python2- prefix renaming, part 2

[Zbigniew Jędrzejewski-Szmek]

On Mon, Dec 18, 2017 at 03:06:35PM +0100, Iryna Shcherbina wrote:
> Hi,
> 
> if the timing is not good, then I can take the generated patch set
> and turn it into Pagure Pull Requests with a script. Packagers would
> be able to review/merge them during the holidays and we can merge
> the rest on January 2nd. This is just a suggestion, let me know if
> it sounds like an idea and if it would be of any help.

Thanks, but I don't think that's necessary. I doubt many packagers
would merge stuff over the holidays, so there wouldn't be much
difference between that and just pushing directly.

I want to use PRs for the few packages that are more complex
(listed in my original e-mail, e.g. kernel and pyqt4), but that's
just ~10 packages, so that can be done by hand.

Zbyszek


> 
> Regards,
> Iryna Shcherbina
> 
> On 12/18/2017 02:41 PM, Zbigniew Jędrzejewski-Szmek wrote:
> >On Mon, Dec 18, 2017 at 01:05:03PM +, Stephen Gallagher wrote:
> >>On Sun, Dec 17, 2017 at 3:16 PM Zbigniew Jędrzejewski-Szmek <
> >>zbys...@in.waw.pl> wrote:
> >>
> >>>Dear fellow Fedora developers,
> >>>
> >>>I plan to execute part 2 of the renaming. First part was announced and
> >>>discussed here [1]. Recently, Iryna Shcherbina announced [2] plans for
> >>>a follow up: changing the requirements. Before that happens I want to
> >>>finish my renaming. In this round my changes are rather small, only
> >>>~80 packages, see the lists below. There's various packages which either
> >>>are not on the porting-db list [3], or are particularly complicated [4],
> >>>or have been fixed in git but don't build, all of which I'm ignoring
> >>>for now.
> >>>
> >>>Short description:
> >>>binary Python2 subpackages with a name starting with "python-" or
> >>>ending with "-python" will be renamed to "python2-…". Provides/Obsoletes
> >>>for the old name are of course added, so upgrades should work and other
> >>>packages using the old names do not need to be adjusted.
> >>>
> >>>In the first round, packages which had Requires/Provides under
> >>>conditionals were skipped. In this round the renamer script [5] was
> >>>improved to support such cases.
> >>>
> >>>Timeline:
> >>>If nothing pops up, I'll push the changes and to the rebuilds on Friday.
> >>>
> >>>
> >>This timeline is a bit concerning. Friday marks the start of the lowest
> >>maintainer activity each year. A huge subset of the Fedora community goes
> >>away to enjoy their winter holidays.
> >>
> >>I think pushing a mass-packaging change on this schedule would be a really
> >>bad idea. It *will* result in breakage. I'd suggest postponing the change
> >>until January 2nd.
> >Actually that's on purpose: I wanted to do the rebuilds over the
> >holidays, without bothering anybody or interfering with anybody's
> >work. In case there are any regressions, people will most likely
> >report them early in January so there'll be time to fix everything
> >when everybody is back to work and fresh.
> >
> >Zbyszek
> >___
> >devel mailing list -- devel@lists.fedoraproject.org
> >To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Introducing myself to Fedora

[Charalampos Stratakis]

- Original Message -
> From: "Spyros Trigazis" 
> To: devel@lists.fedoraproject.org
> Cc: "Dusty Mabe" 
> Sent: Saturday, December 16, 2017 11:37:30 PM
> Subject: Introducing myself to Fedora
> 
> 
> 
> Hello Fedora Developers,
> 
> I would like to join the packagers group and I am sending you
> this email to introduce myself.
> 
> My name is Spyros Trigazis and I'm currently working for the CERN [1]
> Cloud Infrastructure team [2]. More specifically I'm working on
> OpenStack/Magnum [3] and I'm serving as Project Team Lead PTL for
> this OpenStack cycle. Mangum and the CERN Container service,
> are heavy consumers of ProjectAtomic's [4] Fedora Atomic host and
> I try to work close with the atomic team.
> 
> The main reason that I want to join the packagers group is that
> I really respect all the work that is done open and it's offered
> to the open source community free and for free. Of course I have
> a stake to this effort. Magnum and consequently the CERN container
> service are consuming kubernetes from the Fedora and CentOS repos,
> so I would like to co-maintain the package with Jan Chaloupka
> cc-ed with whom I'm in touch for some time now.
> 
> According to the process of joining the packagers team I need
> to be sponsored from the a sponsor-level member, so folks I'm
> looking for sponsor :).
> 
> Looking forward in hearing from you,
> Spyros Trigazis
> 
> [1] https://home.cern/
> [2] http://openstack-in-production.blogspot.ch/
> [3] https://docs.openstack.org/magnum/latest/
> [4] http://www.projectatomic.io/
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 

Hello and welcome to Fedora!

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: updating SuperLU on EL-7 and EL-6

[Ryan Curtin]

On Mon, Dec 18, 2017 at 01:40:12PM +1000, Conrad Sand wrote:
> RHEL6 does have some use within a few Fortune 500 companies for
> running existing backend infrastructure.  The type of infrastructure
> that is meant to be "set-and-forget", modulo security updates.
> 
> However, as a general development platform or a workstation, RHEL6 is
> next to useless, as it's outdated and superseded.  According to
> Wikipedia, RHEL6 is out of "Production 2" support, and in a zombie
> state (ie. "Production 3").  This zombie state will last as "extended"
> support until 2024.  Is anybody going to seriously use the RHEL6
> toolset in 2024 ?
> 
> Using RHEL6 for development, and hence updating EPEL6, in effect
> following the sunk cost fallacy.  A better use of time would be to
> update EPEL7.  RHEL7 is still in "Production 1" phase.

EPEL7 update is in progress.  Very easy to rebuild for EPEL6 too, so
there's little reason not to.

https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e36735026b

Looks like some downstream Armadillo packages need to be rebuilt before
that one is ready.

I know that the Armadillo version is out of date, but we'll push the
soname bump first then I can push the updated patch version.

-- 
Ryan Curtin| "That rug really tied the room together."
r...@ratml.org |   - The Dude
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: wrong selinux label on user-1000.journal, AVC denials

[Lukas Vrabec]

On 12/16/2017 12:04 AM, Chris Murphy wrote:

Fedora 27 workstation. I'm getting selinux AVC denial messages in the
journal as a result of user-1000.journal having label
system_u:object_r:unlabeled_t:s0. It's the only log file with that
label, the other files and the directory its in have
system_u:object_r:var_log_t:s0.

The AVC message of course go away if I relabel /var/log/journal but
then maybe two weeks later the problem starts happening again when the
log gets rotated. For whatever reason this is not happening with the
system.journal.

Dec 15 15:54:47 f27h.localdomain audit[640]: AVC avc:  denied  { read
write } for  pid=640 comm="systemd-journal" name="user-1000.journal"
dev="nvme0n1p9" ino=1174 scontext=system_u:system_r:syslogd_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0

Is this a systemd or selinux-policy bug? Or other?





Michal, what you think about this?

How is the user-100.journal file created? It's end up as unlabeled_t so 
some actions during early state of booting system?


Thanks,
Lukas.


--
Lukas Vrabec
Software Engineer, Security Technologies
Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Introducing myself to Fedora

[Dusty Mabe]

On 12/16/2017 05:37 PM, Spyros Trigazis wrote:
> Hello Fedora Developers,
> 
> I would like to join the packagers group and I am sending you
> this email to introduce myself.
> 
> My name is Spyros Trigazis and I'm currently working for the CERN [1]
> Cloud Infrastructure team [2]. More specifically I'm working on
> OpenStack/Magnum [3] and I'm serving as Project Team Lead PTL for
> this OpenStack cycle. Mangum and the CERN Container service,
> are heavy consumers of ProjectAtomic's [4] Fedora Atomic host and
> I try to work close with the atomic team.
> 
> The main reason that I want to join the packagers group is that
> I really respect all the work that is done open and it's offered
> to the open source communityfree and for free. Of course I have
> a stake to this effort. Magnum and consequently the CERN container
> service are consuming kubernetes from the Fedora and CentOS repos,
> so I would like to co-maintain thepackage with Jan Chaloupka
> cc-ed with whom I'm in touch forsome time now.
> 
> According to the process of joining the packagers team I need
> to be sponsored from the a sponsor-level member, so folks I'm
> looking for sponsor :).
> 
> Looking forward in hearing from you,
> Spyros Trigazis
> 


Welcome Spyros and thank you for the work you've already done in the Atomic
Working Group!

Dusty
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: MASS CHANGE announcement: python2- prefix renaming, part 2

[Iryna Shcherbina]

Hi,

if the timing is not good, then I can take the generated patch set and 
turn it into Pagure Pull Requests with a script. Packagers would be able 
to review/merge them during the holidays and we can merge the rest on 
January 2nd. This is just a suggestion, let me know if it sounds like an 
idea and if it would be of any help.


Regards,
Iryna Shcherbina

On 12/18/2017 02:41 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Mon, Dec 18, 2017 at 01:05:03PM +, Stephen Gallagher wrote:

On Sun, Dec 17, 2017 at 3:16 PM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:


Dear fellow Fedora developers,

I plan to execute part 2 of the renaming. First part was announced and
discussed here [1]. Recently, Iryna Shcherbina announced [2] plans for
a follow up: changing the requirements. Before that happens I want to
finish my renaming. In this round my changes are rather small, only
~80 packages, see the lists below. There's various packages which either
are not on the porting-db list [3], or are particularly complicated [4],
or have been fixed in git but don't build, all of which I'm ignoring
for now.

Short description:
binary Python2 subpackages with a name starting with "python-" or
ending with "-python" will be renamed to "python2-…". Provides/Obsoletes
for the old name are of course added, so upgrades should work and other
packages using the old names do not need to be adjusted.

In the first round, packages which had Requires/Provides under
conditionals were skipped. In this round the renamer script [5] was
improved to support such cases.

Timeline:
If nothing pops up, I'll push the changes and to the rebuilds on Friday.



This timeline is a bit concerning. Friday marks the start of the lowest
maintainer activity each year. A huge subset of the Fedora community goes
away to enjoy their winter holidays.

I think pushing a mass-packaging change on this schedule would be a really
bad idea. It *will* result in breakage. I'd suggest postponing the change
until January 2nd.

Actually that's on purpose: I wanted to do the rebuilds over the
holidays, without bothering anybody or interfering with anybody's
work. In case there are any regressions, people will most likely
report them early in January so there'll be time to fix everything
when everybody is back to work and fresh.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora Rawhide-20171218.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Server boot x86_64
Server dvd i386
Workstation live i386
Server dvd x86_64
Server boot i386
Kde live i386

Failed openQA tests: 51/106 (x86_64), 1/2 (arm)

New failures (same test did not fail in Rawhide-20171217.n.0):

ID: 180966  Test: x86_64 universal install_delete_partial
URL: https://openqa.fedoraproject.org/tests/180966

Old failures (same test failed in Rawhide-20171217.n.0):

ID: 180912  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/180912
ID: 180914  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/180914
ID: 180915  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/180915
ID: 180916  Test: x86_64 Workstation-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/180916
ID: 180925  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/180925
ID: 180927  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/180927
ID: 180928  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/180928
ID: 180930  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/180930
ID: 180932  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/180932
ID: 180943  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/180943
ID: 180944  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/180944
ID: 180946  Test: x86_64 Atomic-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/180946
ID: 180949  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/180949
ID: 180955  Test: x86_64 universal install_delete_pata@uefi
URL: https://openqa.fedoraproject.org/tests/180955
ID: 180957  Test: x86_64 universal install_sata@uefi
URL: https://openqa.fedoraproject.org/tests/180957
ID: 180961  Test: x86_64 universal install_multi@uefi
URL: https://openqa.fedoraproject.org/tests/180961
ID: 180972  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/180972
ID: 180977  Test: x86_64 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/180977
ID: 180978  Test: x86_64 universal install_blivet_lvmthin
URL: https://openqa.fedoraproject.org/tests/180978
ID: 180979  Test: x86_64 universal install_blivet_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/180979
ID: 180980  Test: x86_64 universal install_blivet_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/180980
ID: 180981  Test: x86_64 universal install_blivet_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/180981
ID: 180982  Test: x86_64 universal install_blivet_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/180982
ID: 180983  Test: x86_64 universal install_blivet_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/180983
ID: 180984  Test: x86_64 universal install_blivet_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/180984
ID: 180985  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/180985
ID: 180986  Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/180986
ID: 180987  Test: x86_64 universal install_simple_free_space@uefi
URL: https://openqa.fedoraproject.org/tests/180987
ID: 180988  Test: x86_64 universal install_multi_empty@uefi
URL: https://openqa.fedoraproject.org/tests/180988
ID: 180989  Test: x86_64 universal install_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/180989
ID: 180990  Test: x86_64 universal install_delete_partial@uefi
URL: https://openqa.fedoraproject.org/tests/180990
ID: 180991  Test: x86_64 universal install_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/180991
ID: 180992  Test: x86_64 universal install_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/180992
ID: 180993  Test: x86_64 universal install_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/180993
ID: 180994  Test: x86_64 universal install_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/180994
ID: 180995  Test: x86_64 universal install_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/180995
ID: 180997  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/180997
ID: 180998  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/180998
ID: 180999  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/180999
ID: 181000  Test: x86_64 universal 

Re: MASS CHANGE announcement: python2- prefix renaming, part 2

[Zbigniew Jędrzejewski-Szmek]

On Mon, Dec 18, 2017 at 01:05:03PM +, Stephen Gallagher wrote:
> On Sun, Dec 17, 2017 at 3:16 PM Zbigniew Jędrzejewski-Szmek <
> zbys...@in.waw.pl> wrote:
> 
> > Dear fellow Fedora developers,
> >
> > I plan to execute part 2 of the renaming. First part was announced and
> > discussed here [1]. Recently, Iryna Shcherbina announced [2] plans for
> > a follow up: changing the requirements. Before that happens I want to
> > finish my renaming. In this round my changes are rather small, only
> > ~80 packages, see the lists below. There's various packages which either
> > are not on the porting-db list [3], or are particularly complicated [4],
> > or have been fixed in git but don't build, all of which I'm ignoring
> > for now.
> >
> > Short description:
> > binary Python2 subpackages with a name starting with "python-" or
> > ending with "-python" will be renamed to "python2-…". Provides/Obsoletes
> > for the old name are of course added, so upgrades should work and other
> > packages using the old names do not need to be adjusted.
> >
> > In the first round, packages which had Requires/Provides under
> > conditionals were skipped. In this round the renamer script [5] was
> > improved to support such cases.
> >
> > Timeline:
> > If nothing pops up, I'll push the changes and to the rebuilds on Friday.
> >
> >
> 
> This timeline is a bit concerning. Friday marks the start of the lowest
> maintainer activity each year. A huge subset of the Fedora community goes
> away to enjoy their winter holidays.
> 
> I think pushing a mass-packaging change on this schedule would be a really
> bad idea. It *will* result in breakage. I'd suggest postponing the change
> until January 2nd.

Actually that's on purpose: I wanted to do the rebuilds over the
holidays, without bothering anybody or interfering with anybody's
work. In case there are any regressions, people will most likely
report them early in January so there'll be time to fix everything
when everybody is back to work and fresh.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: MASS CHANGE announcement: python2- prefix renaming, part 2

[Stephen Gallagher]

On Sun, Dec 17, 2017 at 3:16 PM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> Dear fellow Fedora developers,
>
> I plan to execute part 2 of the renaming. First part was announced and
> discussed here [1]. Recently, Iryna Shcherbina announced [2] plans for
> a follow up: changing the requirements. Before that happens I want to
> finish my renaming. In this round my changes are rather small, only
> ~80 packages, see the lists below. There's various packages which either
> are not on the porting-db list [3], or are particularly complicated [4],
> or have been fixed in git but don't build, all of which I'm ignoring
> for now.
>
> Short description:
> binary Python2 subpackages with a name starting with "python-" or
> ending with "-python" will be renamed to "python2-…". Provides/Obsoletes
> for the old name are of course added, so upgrades should work and other
> packages using the old names do not need to be adjusted.
>
> In the first round, packages which had Requires/Provides under
> conditionals were skipped. In this round the renamer script [5] was
> improved to support such cases.
>
> Timeline:
> If nothing pops up, I'll push the changes and to the rebuilds on Friday.
>
>

This timeline is a bit concerning. Friday marks the start of the lowest
maintainer activity each year. A huge subset of the Fedora community goes
away to enjoy their winter holidays.

I think pushing a mass-packaging change on this schedule would be a really
bad idea. It *will* result in breakage. I'd suggest postponing the change
until January 2nd.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: Proposed Fedora packaging guideline: Forge-hosted projects packaging automation

[nicolas . mailhot]

Hi,

> 4. There is a bug in EL7 that causes spectool not to process the resulting 
> files. rpmbuild and mock work fine though. I
> added a -i switch to the macro that prints the resolved source url, you can 
> then dump it in curl, wget or whatever in EL7.
> Alternatively, get someone to fix the EL7 toolchain.

Anyway, with the latest changes, we don't hit the EL7 bug anymore so spectool 
also works in EL7

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

pghmcfc pushed to perl-MCE-Shared (master). "Update to 1.834 (..more)"

[notifications]

From 05cce7a67fa459404710d28b2d01f9dabcf777c0 Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Dec 18 2017 10:45:51 +
Subject: Update to 1.834


- New upstream release 1.834
  - Fixed croak handling inside MCE::Shared::Server
  - Enhanced sequence (bounds_only) to return optional 3rd value (id)
  - Improved seconds method for _delay package inside MCE::Hobo
  - Improved clear and get methods for shared objects
  - Tweaked shared_cache_lru test script

---

diff --git a/perl-MCE-Shared.spec b/perl-MCE-Shared.spec
index 9849ac1..0b3d98f 100644
--- a/perl-MCE-Shared.spec
+++ b/perl-MCE-Shared.spec
@@ -1,5 +1,5 @@
 Name:  perl-MCE-Shared
-Version:   1.833
+Version:   1.834
 Release:   1%{?dist}
 Summary:   MCE extension for sharing data, supporting threads and processes
 License:   GPL+ or Artistic
@@ -98,6 +98,14 @@ make test
 %{_mandir}/man3/MCE::Shared::Server.3*
 
 %changelog
+* Mon Dec 18 2017 Paul Howarth  - 1.834-1
+- Update to 1.834
+  - Fixed croak handling inside MCE::Shared::Server
+  - Enhanced sequence (bounds_only) to return optional 3rd value (id)
+  - Improved seconds method for _delay package inside MCE::Hobo
+  - Improved clear and get methods for shared objects
+  - Tweaked shared_cache_lru test script
+
 * Wed Nov 22 2017 Paul Howarth  - 1.833-1
 - Update to 1.833
   - Condvar timedwait supports floating seconds via Time::HiRes; the
diff --git a/sources b/sources
index 3604e26..8fa5c04 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (MCE-Shared-1.833.tar.gz) = 
55e5a913165d982dfc8b6b22c00a061c1941ce1ec1206e2e5bf75c4ab977c75af62b96797e39d0b9372a40e8a64f42106e02090da73cffc2be09c0960a93d5e2
+SHA512 (MCE-Shared-1.834.tar.gz) = 
8e84ca40ee3a8f9d2166162a7719312471dd881a8cdf0fd7330ff94159f2d7aaf4cda9e5529c5dc22fd86b31552b7f11839ba899543335204fdf968bfe03f6cf



https://src.fedoraproject.org/rpms/perl-MCE-Shared/c/05cce7a67fa459404710d28b2d01f9dabcf777c0?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1526776] perlbrew-0.82 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1526776

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perlbrew-0.82-1.fc28
 Resolution|--- |RAWHIDE
Last Closed||2017-12-18 05:02:00



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1526665] perl-PPI-XS-0.910 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1526665



--- Comment #3 from Fedora Update System  ---
perl-PPI-XS-0.910-1.fc26 has been submitted as an update to Fedora 26.
https://bodhi.fedoraproject.org/updates/FEDORA-2017-a19ecb8240

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1526665] perl-PPI-XS-0.910 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1526665



--- Comment #2 from Fedora Update System  ---
perl-PPI-XS-0.910-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2017-155263b957

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1526665] perl-PPI-XS-0.910 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1526665

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-PPI-XS-0.910-1.fc28



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for all Fedoras.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org