Fedora 20 updates-testing report

[updates]

The following Fedora 20 Security updates need testing:
 Age  URL
 126  
https://admin.fedoraproject.org/updates/FEDORA-2014-11969/krb5-1.11.5-16.fc20
  78  
https://admin.fedoraproject.org/updates/FEDORA-2014-15371/rubygem-actionpack-4.0.0-5.fc20
  77  
https://admin.fedoraproject.org/updates/FEDORA-2014-15489/rubygem-sprockets-2.8.2-5.fc20
  56  
https://admin.fedoraproject.org/updates/FEDORA-2014-16494/mutt-1.5.23-4.fc20
  54  
https://admin.fedoraproject.org/updates/FEDORA-2014-16845/resteasy-3.0.6-3.fc20
  54  
https://admin.fedoraproject.org/updates/FEDORA-2014-16825/asterisk-11.14.2-1.fc20
  49  
https://admin.fedoraproject.org/updates/FEDORA-2014-17153/httpd-2.4.10-2.fc20
  46  
https://admin.fedoraproject.org/updates/FEDORA-2014-17089/aeskulap-0.2.2-0.20beta1.fc20,orthanc-0.8.5-2.fc20,dcmtk-3.6.1-1.fc20
  42  
https://admin.fedoraproject.org/updates/FEDORA-2014-17559/mapserver-6.2.2-1.fc20
  40  
https://admin.fedoraproject.org/updates/FEDORA-2014-17641/dokuwiki-0-0.23.20140929b.fc20
  24  
https://admin.fedoraproject.org/updates/FEDORA-2015-0577/strongswan-5.2.2-1.fc20
  22  
https://admin.fedoraproject.org/updates/FEDORA-2015-0633/chicken-4.9.0.1-3.fc20
  19  https://admin.fedoraproject.org/updates/FEDORA-2015-0773/arc-5.21p-5.fc20
  16  
https://admin.fedoraproject.org/updates/FEDORA-2015-0951/xdg-utils-1.1.0-0.35.rc3.fc20
  15  
https://admin.fedoraproject.org/updates/FEDORA-2015-1007/dump-0.4-0.24.b44.fc20
  11  
https://admin.fedoraproject.org/updates/FEDORA-2015-1162/community-mysql-5.5.41-1.fc20
  11  
https://admin.fedoraproject.org/updates/FEDORA-2015-1159/jasper-1.900.1-28.fc20
   8  
https://admin.fedoraproject.org/updates/FEDORA-2015-1294/qpid-cpp-0.30-7.fc20
   6  
https://admin.fedoraproject.org/updates/FEDORA-2015-1439/websvn-2.3.3-8.fc20
   6  
https://admin.fedoraproject.org/updates/FEDORA-2015-1354/firefox-35.0.1-3.fc20
   6  
https://admin.fedoraproject.org/updates/FEDORA-2015-1364/mantis-1.2.19-1.fc20
   5  
https://admin.fedoraproject.org/updates/FEDORA-2015-1263/maradns-2.0.11-1.fc20
   5  https://admin.fedoraproject.org/updates/FEDORA-2015-1510/pigz-2.3.3-1.fc20
   3  
https://admin.fedoraproject.org/updates/FEDORA-2015-1165/patch-2.7.4-1.fc20
   1  https://admin.fedoraproject.org/updates/FEDORA-2015-1648/lcms-1.19-13.fc20
   1  
https://admin.fedoraproject.org/updates/FEDORA-2015-1672/kernel-3.18.5-101.fc20
   0  
https://admin.fedoraproject.org/updates/FEDORA-2015-1728/postgresql-9.3.6-1.fc20
   0  
https://admin.fedoraproject.org/updates/FEDORA-2015-1699/bugzilla-4.2.13-1.fc20
   0  
https://admin.fedoraproject.org/updates/FEDORA-2015-1700/puppetlabs-stdlib-4.5.1-2.20150121git7a91f20.fc20
   0  
https://admin.fedoraproject.org/updates/FEDORA-2015-1759/ntp-4.2.6p5-20.fc20
   0  
https://admin.fedoraproject.org/updates/FEDORA-2015-1761/roundcubemail-1.0.5-1.fc20
   0  
https://admin.fedoraproject.org/updates/FEDORA-2015-1762/perl-Gtk2-1.2495-1.fc20


The following Fedora 20 Critical Path updates have yet to be approved:
 Age URL
  16  
https://admin.fedoraproject.org/updates/FEDORA-2015-0951/xdg-utils-1.1.0-0.35.rc3.fc20
  11  
https://admin.fedoraproject.org/updates/FEDORA-2015-1095/perl-Filter-1.54-1.fc20
  11  
https://admin.fedoraproject.org/updates/FEDORA-2015-1159/jasper-1.900.1-28.fc20
  10  
https://admin.fedoraproject.org/updates/FEDORA-2015-1214/hwdata-0.274-2.fc20
   8  
https://admin.fedoraproject.org/updates/FEDORA-2015-1285/polkit-0.112-7.fc20.1
   6  
https://admin.fedoraproject.org/updates/FEDORA-2015-1425/perl-Getopt-Long-2.43-1.fc20
   6  
https://admin.fedoraproject.org/updates/FEDORA-2015-1434/perl-Pod-Simple-3.29-1.fc20
   6  
https://admin.fedoraproject.org/updates/FEDORA-2015-1448/koji-1.9.0-10.fc20.gitcd45e886
   6  
https://admin.fedoraproject.org/updates/FEDORA-2015-1384/cairo-1.14.0-1.fc20
   6  
https://admin.fedoraproject.org/updates/FEDORA-2015-1423/amor-14.12.1-1.fc20,ark-14.12.1-1.fc20,audiocd-kio-14.12.1-1.fc20,blinken-14.12.1-1.fc20,cantor-14.12.1-1.fc20,dragon-14.12.1-1.fc20,filelight-14.12.1-1.fc20,jovie-14.12.1-2.fc20,juk-14.12.1-1.fc20,kaccessible-14.12.1-1.fc20,kalzium-14.12.1-1.fc20,kamera-14.12.1-1.fc20,kanagram-4.14.3-3.fc20,kbruch-14.12.1-1.fc20,kcalc-14.12.1-1.fc20,kcharselect-14.12.1-1.fc20,kcolorchooser-14.12.1-1.fc20,kcron-14.12.1-2.fc20,kdeartwork-14.12.1-1.fc20,kde-baseapps-14.12.1-1.fc20,kde-base-artwork-14.12.1-1.fc20,kdegraphics-mobipocket-14.12.1-1.fc20,kdegraphics-strigi-analyzer-14.12.1-1.fc20,kdegraphics-thumbnailers-14.12.1-1.fc20,kdelibs-4.14.4-2.fc20,kdenetwork-filesharing-14.12.1-1.fc20,kdenetwork-strigi-analyzers-14.12.1-1.fc20,kdepim-4.14.4-2.fc20,kdepimlibs-4.14.4-1.fc20,kdepim-runtime-4.14.4-1.fc20,kdeplasma-addons-4.14.3-3.fc20,kde-runtime-14.12.1-2.fc20,kde-wallpapers-14.12.1-1.fc20,kdf-14.12.1-1.fc20,kdnssd-14.12.1-1.fc20,kfloppy-14.12.1-1.fc20,kgamma-14.12.1-1.fc20,kgeography-14.12.1-1.fc20,kget-14.12.1-1.fc20,kgpg-14.12.1-1.fc20,khangman-4.14.3-3.fc20,kiten-14.12.1-1.fc20,klettres-14.12.1-1.fc20,kmag-14.12

Fedora 21 updates-testing report

[updates]

The following Fedora 21 Security updates need testing:
 Age  URL
  79  
https://admin.fedoraproject.org/updates/FEDORA-2014-15342/rubygem-actionpack-4.1.5-2.fc21
  77  
https://admin.fedoraproject.org/updates/FEDORA-2014-15413/rubygem-sprockets-2.12.1-3.fc21
  55  
https://admin.fedoraproject.org/updates/FEDORA-2014-16782/mutt-1.5.23-7.fc21
  54  
https://admin.fedoraproject.org/updates/FEDORA-2014-16833/asterisk-11.14.2-1.fc21
  49  
https://admin.fedoraproject.org/updates/FEDORA-2014-17195/httpd-2.4.10-15.fc21
  46  
https://admin.fedoraproject.org/updates/FEDORA-2014-17139/aeskulap-0.2.2-0.20beta1.fc21,orthanc-0.8.5-2.fc21,dcmtk-3.6.1-1.fc21
  42  
https://admin.fedoraproject.org/updates/FEDORA-2014-17567/mapserver-6.2.2-1.fc21
  40  
https://admin.fedoraproject.org/updates/FEDORA-2014-17635/dokuwiki-0-0.23.20140929b.fc21
  30  https://admin.fedoraproject.org/updates/FEDORA-2015-0264/gcab-0.4-7.fc21
  24  
https://admin.fedoraproject.org/updates/FEDORA-2015-0594/strongswan-5.2.2-1.fc21
  22  
https://admin.fedoraproject.org/updates/FEDORA-2015-0620/chicken-4.9.0.1-3.fc21
  19  https://admin.fedoraproject.org/updates/FEDORA-2015-0754/arc-5.21p-5.fc21
  16  
https://admin.fedoraproject.org/updates/FEDORA-2015-0938/android-tools-20141219git8393e50-2.fc21
  15  
https://admin.fedoraproject.org/updates/FEDORA-2015-1023/dump-0.4-0.24.b44.fc21
  11  
https://admin.fedoraproject.org/updates/FEDORA-2015-1062/jasper-1.900.1-30.fc21
   6  
https://admin.fedoraproject.org/updates/FEDORA-2015-1419/mantis-1.2.19-1.fc21
   6  
https://admin.fedoraproject.org/updates/FEDORA-2015-1467/openstack-glance-2014.1.3-4.fc21
   6  
https://admin.fedoraproject.org/updates/FEDORA-2015-1465/websvn-2.3.3-8.fc21
   5  https://admin.fedoraproject.org/updates/FEDORA-2015-1488/pigz-2.3.3-1.fc21
   2  
https://admin.fedoraproject.org/updates/FEDORA-2015-1570/qpid-cpp-0.30-9.fc21
   1  
https://admin.fedoraproject.org/updates/FEDORA-2015-1632/virt-who-0.8-11.fc21
   0  
https://admin.fedoraproject.org/updates/FEDORA-2015-1708/puppetlabs-stdlib-4.5.1-2.20150121git7a91f20.fc21
   0  
https://admin.fedoraproject.org/updates/FEDORA-2015-1736/ntp-4.2.6p5-27.fc21
   0  
https://admin.fedoraproject.org/updates/FEDORA-2015-1713/bugzilla-4.4.8-1.fc21.1
   0  
https://admin.fedoraproject.org/updates/FEDORA-2015-1751/moodle-2.7.5-1.fc21
   0  
https://admin.fedoraproject.org/updates/FEDORA-2015-1745/postgresql-9.3.6-1.fc21
   0  
https://admin.fedoraproject.org/updates/FEDORA-2015-1733/perl-Gtk2-1.2495-1.fc21
   0  
https://admin.fedoraproject.org/updates/FEDORA-2015-1772/roundcubemail-1.0.5-1.fc21


The following Fedora 21 Critical Path updates have yet to be approved:
 Age URL
  11  
https://admin.fedoraproject.org/updates/FEDORA-2015-1091/perl-Filter-1.54-1.fc21
  11  
https://admin.fedoraproject.org/updates/FEDORA-2015-1152/imlib2-1.4.6-3.fc21
  11  
https://admin.fedoraproject.org/updates/FEDORA-2015-1062/jasper-1.900.1-30.fc21
  10  
https://admin.fedoraproject.org/updates/FEDORA-2015-1254/rygel-0.24.3-1.fc21
   6  
https://admin.fedoraproject.org/updates/FEDORA-2015-1456/perl-Getopt-Long-2.43-1.fc21
   6  
https://admin.fedoraproject.org/updates/FEDORA-2015-1454/perl-Pod-Simple-3.29-1.fc21
   6  
https://admin.fedoraproject.org/updates/FEDORA-2015-1436/koji-1.9.0-10.fc21.gitcd45e886
   5  https://admin.fedoraproject.org/updates/FEDORA-2015-1488/pigz-2.3.3-1.fc21
   2  
https://admin.fedoraproject.org/updates/FEDORA-2015-1597/bind-9.9.6-7.P1.fc21
   1  
https://admin.fedoraproject.org/updates/FEDORA-2015-1669/highlight-3.21-1.fc21
   1  
https://admin.fedoraproject.org/updates/FEDORA-2015-1662/sqlite-3.8.8-2.fc21
   1  
https://admin.fedoraproject.org/updates/FEDORA-2015-1641/perl-version-0.99.12-1.fc21
   0  
https://admin.fedoraproject.org/updates/FEDORA-2015-1725/perl-Encode-2.70-1.fc21
   0  
https://admin.fedoraproject.org/updates/FEDORA-2015-1768/selinux-policy-3.13.1-105.3.fc21
   0  
https://admin.fedoraproject.org/updates/FEDORA-2015-1763/systemd-216-18.fc21
   0  
https://admin.fedoraproject.org/updates/FEDORA-2015-1769/xorg-x11-drv-synaptics-1.8.1-3.fc21


The following builds have been pushed to Fedora 21 updates-testing

389-ds-base-1.3.3.8-1.fc21
389-ds-console-1.2.9-1.fc21
RackTables-0.20.10-1.fc21
claws-mail-3.11.1-6.fc21
cln-1.3.4-1.fc21
csvcat-0.1-20141205git858edfe.fc21
dnf-langpacks-0.7.0-2.fc21
dovecot-2.2.15-3.fc21
fdm-1.8-1.fc21
gammaray-2.2.1-3.fc21
gedit-3.14.3-1.fc21
idm-console-framework-1.1.9-1.fc21
kf5-kguiaddons-5.6.0-2.fc21
minised-1.15-1.fc21
moodle-2.7.5-1.fc21
ntp-4.2.6p5-27.fc21
open-vm-tools-9.4.6-6.fc21
openbabel-2.3.2-11.fc21
perl-Encode-2.70-1.fc21
perl-Gtk2-1.2495-1.fc21
pgp-tools-1.1.12-2.fc21
php-pecl-mongo-1.6.1-1.fc21
postgresql-9.3.6-1.fc21
publicsuffix-list-20150204-1.fc21
python-paho-mqtt-1.1-1.fc21
python-sphinx-1.2.3-1.fc21
roundcubemail-1.0.5-1.fc21
rpcbind-0.2.2-2.1.fc21
rubygem

Re: Rawhide - Rpmfusion

[Mike Chambers]

On Wed, 2015-02-04 at 22:54 -0800, Chuck Forsberg WA7KGX wrote:
> When when Rpmfusion be available for Rawhide?
> 


Might ask that on the rpmfusion mailing list.


-- 
Mike Chambers
Madisonville, KY

"Best little town on Earth!"

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Release criteria notes

[Adam Williamson]

On Thu, 2015-02-05 at 11:24 -0700, Mike Ruckman wrote:
> Greetings testers!
> 
> While looking into the affects of the yum/dnf migration I noticed 
> some cleanup
> opportunities with the release criteria and thought I'd email the 
> list before
> making any changes.
> 
> Beta
> 
> 
> Package set selection
> 
>   Should we update this to say "when using any network install 
> image..."
>   instead of "when using the generic?" I'd add a note with something 
> like,
>   "[Any?] This means any of the productized network installation 
> media and
>   the base network installation image."

No. I only just wrote this, and it's specifically this way for a 
reason. We're getting the generic netinst back for F22, and we only 
want to 'officially support' package set selection when using that 
image. The Product-ized netinsts are only 'officially supported' for 
deploying their own package sets. At least, that's the current plan.

> 
> Kickstart Delivery
> 
>   Not really a criterion change, but we still list a diskette as a 
> supported
>   delivery mechanism [0]. Should we remove this, or do we still 
> actively test
>   using a diskette for ks delivery?

Hum, not sure. I know I haven't had a floppy drive for like ten years 
so it might be hard to test, but people do do a lot of really weird 
stuff.

> Updgrade Requirements
> 
>   This currently reads: "The release-blocking package sets are the 
> minimal set,
>   and the sets for each one of the release-blocking desktops."
> 
>   Should this be updated to "each one of the release-blocking 
> products and
>   release-blocking desktops?"

Probably, yeah. It's a bit wiggly either way, but I like that one 
better...

> Domain controller role
> 
>   The note says this criteria should be removed after F21 - but 
> since rolekit
>   relies on yum to install the bits needed for the domain 
> controller, should
>   we keep this in place for F22 through the dnf migration?

It's supposed to be *moved* to a separate page, not just removed. I've 
had that proposal in draft for a while now, I should probably just go 
ahead and do it:

https://lists.fedoraproject.org/pipermail/server/2015-January/001719.html

> Cloud-init
> 
>   This was an oversight on my part originally. We need to define the 
> specific
>   bits of cloud-init that need to work. It'd be nice and easy to 
> just say,
>   "all of them," but cloud-init has a yum module and no dnf module. 
> We need
>   to figure out what to do about cloud-init if dnf support won't be 
> added.

And by 'we', we mean 'you' ;)

> Role installation
> 
>   For at least F22, do we need to have a criterion for installing 
> new roles
>   with rolekit? Or will "brought to a working configuration" cover 
> this enough?

It might be worth explicitly covering that, yeah, I'll look at it when 
I come back to the role criteria change.

> Final
> =
> 
> Domain controller role
> 
>   As with the beta, I'd suggest we keep this through F22 to make 
> sure things
>   work.

Ditto Beta, it's not supposed to just 'disappear', it's just a 
rearrangement so we don't wind up with the criteria stuffed with 
requirements for X different server roles when we have more.

> I know herding the Release Criteria is typically an Adam thing, 

It's not! Please! I would love if I never had to touch a release 
criterion again! Please, more people work on them! What do I have to 
do to get rid of this perception :P

I work on them because *someone* has to do it, but the more other 
folks want to step in with ideas, the better...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

[Adam Williamson]

On Thu, 2015-02-05 at 13:59 -0500, Felix Miata wrote:
> Brian C. Lane composed on 2015-02-05 09:36 (UTC-0800):
> 
> > We should be
> > encouraging them to choose stronger passwords and we should 
> > remember that we're not the only people running Fedora.
> 
> BIG difference between encouraging, and paternalistic forcing. 
> Forcing is
> what happens to slaves and prisoners. Encouragment is better at 
> leading to
> acceptance than brutality.

OK, seriously, I did warn you. Likening the behaviour of other 
contributors to slavery, prison and brutality is a flagrant violation 
of the Fedora code of conduct. I'm placing your messages on moderation 
for the next week or two at least.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

[Rick Stevens]

On 02/05/2015 01:27 PM, Scott Robbins wrote:

On Thu, Feb 05, 2015 at 12:53:45PM -0700, Chris Murphy wrote:

On Thu, Feb 5, 2015 at 10:36 AM, Brian C. Lane  wrote:


Next to impossible? Really? I've find it easy to come up with passwords
that work.


You think this is easy. Other's don't. It's a condescending,
pointless, and unwinnable argument, and it needs to stop.


You might also look at the CentOS list, which has a high percentage of
people who, y'know, actually use this stuff to make a living.  You'll find
that it's overwhelmingly against this.


I don't find any of the arguments against the change to be compelling.


Well, I don't find any of the arguments for a change, that will probably
violate POLA (principle of least astonishment) at all compelling.  You're
making the change, it is up to you to justify.

This reminds me of the time when they wanted packagekit to allow any user
to upgrade any package--even now, any user can upgrade any installed,
signed package--and they were going to go through with it till it made the
front page of slashdot.


I have to agree with Chris. I have absolutely no issue with the
installer _warning_ me that the password I chose is (in the INSTALLER's
opinion) weak. The installer should ABSOLUTELY NOT force me to use some
arbitrarily obscure password to satisfy its criteria.  I have very good
reasons for using the passwords I choose.

One example: We often have accounts that log in to collect data (e.g.
nagios or rancid) for monitoring purposes or config change deltas. If
the installer suddenly changes the password requirements, then the
existing systems all have to be changed to match, and the monitoring
software also has to be reconfigured. That is truly invasive. I manage
well over 400 systems spread around in three data centers and I have to
change everything because some self-righteous coder thinks my passwords
are inadequate?

All the installer should do is install a functional system. If
something comes up that may be odd, then fine, warn the user about it
but do what the user tells you to do. Leave it up to the system admins
to harden the system if they need to.


We should be
encouraging them to choose stronger passwords and we should remember
that we're not the only people running Fedora.


Yes, but most running Fedora aren't totally inexperienced.  Nor for that
matter, are people running Mint or Ubuntu--most have at least some
knowledge of computers, otherwise, they run Windows or OSX.



Encouraging is one hell of a lot different than beating them over the
head and not letting them configure the system THE WAY THEY WANT IT
CONFIGURED!

--
- Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com -
- AIM/Skype: therps2ICQ: 22643734Yahoo: origrps2 -
--
-"You think that's tough?  Try herding cats!"-
--
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

[Leslie S Satenstein]

 Regards 
 Leslie
 Mr. Leslie SatensteinMontréal Québec, Canada

 
  From: Máirín Duffy 
 To: Discussion of Development and Customization of the Red Hat Linux Installer 
 
Cc: For testing and quality assurance of Fedora releases 
 
 Sent: Thursday, February 5, 2015 4:03 PM
 Subject: Re: Heads up - Anaconda 22.17 will enforce 'good' passwords
   


On 02/05/2015 12:36 PM, Brian C. Lane wrote:
> Next to impossible? Really? I've find it easy to come up with passwords
> that work. We even report libpwquality's reason for any failures.

'my name is' (good) (10 chars)
'bacon4eva!' (strong) (10 chars)
'hamncheese.' (strong) (10 chars)
'GoPatriots!' (strong) (11 chars)
'hey, you!' (good) (8 chars)
'8crayons.' (good) (9 chars)
'latte2015' (good) (9 chars)


I tried making up some passwords in Anaconda in F21, which uses the same 
library. I had a difficult time making a password rated less than good 
when I made passwords that were 10 characters with only lowercase 
letters and no spaces or special characters. Add spaces, a punctuation 
mark, or caps and it is instantly easier. I had a much harder time 
making a new acceptable password for my Twitter account.

Is the concern that 10 chars is too long?



~m

___
Anaconda-devel-list mailing list
anaconda-devel-l...@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list


All passwords of 8 characters are good, but some are better than other.
In the past, I while installing, I used the simplist of passwords. On first 
logon, I then created a more sophisticated one, using  € and ¥ and some other 
characters.
For testing I propose to use ###abc123   for nine characters. Don't know if 
letter repeats of more than 2 characters will be permitted. It would be nice to 
have the acceptance rule.
   
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

[Scott Robbins]

On Thu, Feb 05, 2015 at 12:53:45PM -0700, Chris Murphy wrote:
> On Thu, Feb 5, 2015 at 10:36 AM, Brian C. Lane  wrote:
> 
> > Next to impossible? Really? I've find it easy to come up with passwords
> > that work.
> 
> You think this is easy. Other's don't. It's a condescending,
> pointless, and unwinnable argument, and it needs to stop.

You might also look at the CentOS list, which has a high percentage of
people who, y'know, actually use this stuff to make a living.  You'll find
that it's overwhelmingly against this.

> > I don't find any of the arguments against the change to be compelling.

Well, I don't find any of the arguments for a change, that will probably
violate POLA (principle of least astonishment) at all compelling.  You're
making the change, it is up to you to justify.  

This reminds me of the time when they wanted packagekit to allow any user
to upgrade any package--even now, any user can upgrade any installed,
signed package--and they were going to go through with it till it made the
front page of slashdot.


> >We should be
> > encouraging them to choose stronger passwords and we should remember
> > that we're not the only people running Fedora.

Yes, but most running Fedora aren't totally inexperienced.  Nor for that
matter, are people running Mint or Ubuntu--most have at least some
knowledge of computers, otherwise, they run Windows or OSX.


-- 
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

[Chris Murphy]

On Thu, Feb 5, 2015 at 10:36 AM, Brian C. Lane  wrote:

> Next to impossible? Really? I've find it easy to come up with passwords
> that work.

You think this is easy. Other's don't. It's a condescending,
pointless, and unwinnable argument, and it needs to stop.

I tried anaconda 22.17. I failed to produce an acceptable 8 character
password, and tolerated a 10 character one to appease the installer,
which was promptly forgotten 1/2 an hour later. While humorous, it
also pissed me off. That's not a good UX by definition but I know you
tend to discard negative UX whenever you disagree with the actions of
the user.

> I don't think we should make it act differently. While the change
> request for sshd setup was the initial reason I wrote the changes, I
> think that ALL passwords on the system need to be strong these days.

You keep trying to frame this as weak vs strong passwords, and that's
simply wrong. It's a very weak vs weak password difference, yet it
comes with a disproportionate burden on the user. Every single device
I own, and even ATMs I don't own, have better security and a truly
easy UX than this policy proposes.

> I don't find any of the arguments against the change to be compelling.

I also notice how many times you defend this policy change with "I".
You find it easy, you think it's needed, you find others' arguments
uncompelling. It's just more of the same casting aside of user
opinions that you merely disagree with. And disagreement with the
opinions of others isn't a defense that withstands scrutiny.

Do you find it conspicuous that in a ~70 email thread that no one
except you has posted in favor of the change? The strongest statement
in favor of it that I've read, other than yours, is from sgallagh, in
the Server WG meeting minutes. [1]

16:34:28  A more reasonable approach would be to just
enforce a better root password (not more complex, just longer)

Adamw's hyperbole notwithstanding, his sentiment in that same meeting
is compatible with mine: quit job, and buy a yak farm instead of
typing long passwords a dozen fking times a day.

I surmise the Server WG would reject the current behavior in 22.17
also due to the (capricious) complexity required, and if so there
wouldn't be a misalignment requiring separate behavior between Server
and Workstation.

>We should be
> encouraging them to choose stronger passwords and we should remember
> that we're not the only people running Fedora.

Encourage: - give support and advice to (someone) so that they will do
or continue to do something
Coerce:  - persuade (an unwilling person) to do something by using
force or threats

22.17 forces me to use a weak instead of very weak password, or I'm
disallowed from installing. That behavior meets the definition of
coercion, not encouragement.


[1]
http://meetbot.fedoraproject.org/fedora-meeting-1/2015-01-13/fedora-meeting-1.2015-01-13-16.00.log.html


-- 
Chris Murphy
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

[Felix Miata]

Brian C. Lane composed on 2015-02-05 09:36 (UTC-0800):

> We should be
> encouraging them to choose stronger passwords and we should remember
> that we're not the only people running Fedora.

BIG difference between encouraging, and paternalistic forcing. Forcing is
what happens to slaves and prisoners. Encouragment is better at leading to
acceptance than brutality.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Release criteria notes

[Mike Ruckman]

Greetings testers!

While looking into the affects of the yum/dnf migration I noticed some cleanup
opportunities with the release criteria and thought I'd email the list before
making any changes.

Beta


Package set selection

  Should we update this to say "when using any network install image..."
  instead of "when using the generic?" I'd add a note with something like,
  "[Any?] This means any of the productized network installation media and
  the base network installation image."

Kickstart Delivery

  Not really a criterion change, but we still list a diskette as a supported
  delivery mechanism [0]. Should we remove this, or do we still actively test
  using a diskette for ks delivery?

Updgrade Requirements

  This currently reads: "The release-blocking package sets are the minimal set,
  and the sets for each one of the release-blocking desktops."

  Should this be updated to "each one of the release-blocking products and 
  release-blocking desktops?"

Domain controller role

  The note says this criteria should be removed after F21 - but since rolekit
  relies on yum to install the bits needed for the domain controller, should
  we keep this in place for F22 through the dnf migration?

Cloud-init

  This was an oversight on my part originally. We need to define the specific
  bits of cloud-init that need to work. It'd be nice and easy to just say, 
  "all of them," but cloud-init has a yum module and no dnf module. We need
  to figure out what to do about cloud-init if dnf support won't be added.

Role installation

  For at least F22, do we need to have a criterion for installing new roles
  with rolekit? Or will "brought to a working configuration" cover this enough?

Final
=

Domain controller role

  As with the beta, I'd suggest we keep this through F22 to make sure things
  work.

I know herding the Release Criteria is typically an Adam thing, but thought
I'd go ahead and ping the list with these small bits.

Thoughts?

[0] 
http://fedoraproject.org/wiki/Anaconda/Kickstart#Chapter_6._Making_the_Kickstart_File_Available

-- 
// Mike 
--
Fedora QA
freenode: roshi
http://roshi.fedorapeople.org
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

[Brian C. Lane]

On Thu, Feb 05, 2015 at 10:47:44AM -0500, David Cantrell wrote:
> On Thu, Feb 05, 2015 at 09:53:30AM +0100, Matthias Clasen wrote:
> > On Mon, 2015-02-02 at 18:38 -0500, David Cantrell wrote:
> > > On Sun, Feb 01, 2015 at 09:53:05PM -0500, Matthias Clasen wrote:
> > > > On Fri, 2015-01-30 at 14:03 -0800, Adam Williamson wrote:
> > > > 
> > > > > I think the main point is the one nirik made; I don't think the devs 
> > > > > agree with your assessment of how significant this is. It's a minor 
> > > > > inconvenience; you just have to come up with a password that passes 
> > > > > the check, or use a kickstart. So I don't think they agree that it 
> > > > > needs a full-blown security audit and FESCo review or whatever, 
> > > > > because they don't think it's really that huge of a change in 
> > > > > behaviour.
> > > > 
> > > > Having to come up with a password that passes the check is not 'a minor
> > > > inconvenience'. Given how capricious libpwquality is about scoring
> > > > (there have been some examples in this thread, there are more in
> > > > gnome-initial-setup bugs), it is next to impossible.

Next to impossible? Really? I've find it easy to come up with passwords
that work. We even report libpwquality's reason for any failures.

> > > > This discussion has been pretty heated, but I agree with there being
> > > > some aspect of 'collective punishment' here: just because _some_ systems
> > > > get installed with sshd enabled, all users who install the Workstation
> > > > have to spend a couple of frustrating minutes trying to find a password
> > > > that gets them past this hurdle.
> > > > 
> > > > If this change stays, I anticipate the Workstation WG asking for a way
> > > > to the workstation installer not enforce this. I know the anaconda folks
> > > > are not eager to add variations like this, but that is exactly what we
> > > > need: If you want to enforce product-specific policy in the installer,
> > > > it needs to be a product-specific installer.
> > > 
> > > You're assuming before asking.  With the structure of the installer now, 
> > > we
> > > can look at changes like taking the password aspect and making it
> > > product-specific controllable by a number of different methods.  Our
> > > historic aim to end variant specifics in the installer was because the old
> > > code (and variants) lacked a way to assign owners to those product
> > > specifics, which meant that requests of the installer to be product 
> > > specific
> > > meant we were asked to be the owners of those specifics.
> > 
> > Let me ask now, then: can we make the change to reject 'weak' passwords
> > specific to only those products that enable sshd by default, please ?
> 
> [adding anaconda-devel-list to CC]
> 
> >From a technical standpoint, I see this being possible.  Conditionalize it
> on sshd being enabled or not.  That's not really variant-specific and just a
> system condition we could work around.
> 
> I'm putting this on anaconda-devel-list for further discussion.  bcl,
> others?  What are your thoughts on this request?

I don't think we should make it act differently. While the change
request for sshd setup was the initial reason I wrote the changes, I
think that ALL passwords on the system need to be strong these days.

I don't find any of the arguments against the change to be compelling.
The most valid one is repeated installs of throw-away VMs, and I
addressed that in my original post. Just make up a password that passes
and write it down.

If we do make this conditional, either based on sshd being active, or
per-product then where do we stop? Most decisions the installer makes
about the system could be called 'enforcing', so do we now have to have
a vote on every change?

Passwords are the gateway to people's private data. We should be
encouraging them to choose stronger passwords and we should remember
that we're not the only people running Fedora.

-- 
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

[David Cantrell]

On Thu, Feb 05, 2015 at 09:53:30AM +0100, Matthias Clasen wrote:
> On Mon, 2015-02-02 at 18:38 -0500, David Cantrell wrote:
> > On Sun, Feb 01, 2015 at 09:53:05PM -0500, Matthias Clasen wrote:
> > > On Fri, 2015-01-30 at 14:03 -0800, Adam Williamson wrote:
> > > 
> > > > I think the main point is the one nirik made; I don't think the devs 
> > > > agree with your assessment of how significant this is. It's a minor 
> > > > inconvenience; you just have to come up with a password that passes 
> > > > the check, or use a kickstart. So I don't think they agree that it 
> > > > needs a full-blown security audit and FESCo review or whatever, 
> > > > because they don't think it's really that huge of a change in 
> > > > behaviour.
> > > 
> > > Having to come up with a password that passes the check is not 'a minor
> > > inconvenience'. Given how capricious libpwquality is about scoring
> > > (there have been some examples in this thread, there are more in
> > > gnome-initial-setup bugs), it is next to impossible.
> > > 
> > > This discussion has been pretty heated, but I agree with there being
> > > some aspect of 'collective punishment' here: just because _some_ systems
> > > get installed with sshd enabled, all users who install the Workstation
> > > have to spend a couple of frustrating minutes trying to find a password
> > > that gets them past this hurdle.
> > > 
> > > If this change stays, I anticipate the Workstation WG asking for a way
> > > to the workstation installer not enforce this. I know the anaconda folks
> > > are not eager to add variations like this, but that is exactly what we
> > > need: If you want to enforce product-specific policy in the installer,
> > > it needs to be a product-specific installer.
> > 
> > You're assuming before asking.  With the structure of the installer now, we
> > can look at changes like taking the password aspect and making it
> > product-specific controllable by a number of different methods.  Our
> > historic aim to end variant specifics in the installer was because the old
> > code (and variants) lacked a way to assign owners to those product
> > specifics, which meant that requests of the installer to be product specific
> > meant we were asked to be the owners of those specifics.
> 
> Let me ask now, then: can we make the change to reject 'weak' passwords
> specific to only those products that enable sshd by default, please ?

[adding anaconda-devel-list to CC]

From a technical standpoint, I see this being possible.  Conditionalize it
on sshd being enabled or not.  That's not really variant-specific and just a
system condition we could work around.

I'm putting this on anaconda-devel-list for further discussion.  bcl,
others?  What are your thoughts on this request?

-- 
David Cantrell 
Manager, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

[Fedora QA] #458: Proposed Test Day - Cockpit

[Fedora QA]

#458: Proposed Test Day - Cockpit
--+
 Reporter:  stefw |   Owner:
 Type:  task  |  Status:  new
 Priority:  major |   Milestone:  Fedora 22
Component:  Test Day  | Version:
 Keywords:|  Blocked By:
 Blocking:|
--+
 Ownership - Stef Walter and the Cockpit team

 Time frame - 23-03-2015

 Feature(s) - General Cockpit Testing and:

 http://fedoraproject.org/wiki/Changes/CockpitDomainController

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

[Scott Robbins]

On Thu, Feb 05, 2015 at 09:38:52AM +, Andre Robatino wrote:
> Matthias Clasen  redhat.com> writes:
> 
> > Let me ask now, then: can we make the change to reject 'weak' passwords
> > specific to only those products that enable sshd by default, please ?
> 
> If the only concern is remote attacks, I'd like to see someone answer the
> earlier question about whether Fedora has password rate and retry limits to
> allow a weak password to be adequately secure, and if not, why not fix that
> instead of requiring a strong password?

As someone said on the CentOS list, where, like most places, it's generally
being received unfavorably, this is similar to the security theatre we have
here in the US, where the TSA inconveniences anyone, at will, with little
real effect, but it makes a nice show. 

In my admittedly biased opinion, that's the best description I've seen.
Will it stop one or two events?  Probably.  Is it effective?  No.  Will it
inconvenience the vast majority?  Yes.

Are Fedora users so inexperienced and stupid that it's necessary?  
I don't think so.

-- 
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

[Andre Robatino]

Matthias Clasen  redhat.com> writes:

> Let me ask now, then: can we make the change to reject 'weak' passwords
> specific to only those products that enable sshd by default, please ?

If the only concern is remote attacks, I'd like to see someone answer the
earlier question about whether Fedora has password rate and retry limits to
allow a weak password to be adequately secure, and if not, why not fix that
instead of requiring a strong password?



-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

[Matthias Clasen]

On Mon, 2015-02-02 at 18:38 -0500, David Cantrell wrote:
> On Sun, Feb 01, 2015 at 09:53:05PM -0500, Matthias Clasen wrote:
> > On Fri, 2015-01-30 at 14:03 -0800, Adam Williamson wrote:
> > 
> > > I think the main point is the one nirik made; I don't think the devs 
> > > agree with your assessment of how significant this is. It's a minor 
> > > inconvenience; you just have to come up with a password that passes 
> > > the check, or use a kickstart. So I don't think they agree that it 
> > > needs a full-blown security audit and FESCo review or whatever, 
> > > because they don't think it's really that huge of a change in 
> > > behaviour.
> > 
> > Having to come up with a password that passes the check is not 'a minor
> > inconvenience'. Given how capricious libpwquality is about scoring
> > (there have been some examples in this thread, there are more in
> > gnome-initial-setup bugs), it is next to impossible.
> > 
> > This discussion has been pretty heated, but I agree with there being
> > some aspect of 'collective punishment' here: just because _some_ systems
> > get installed with sshd enabled, all users who install the Workstation
> > have to spend a couple of frustrating minutes trying to find a password
> > that gets them past this hurdle.
> > 
> > If this change stays, I anticipate the Workstation WG asking for a way
> > to the workstation installer not enforce this. I know the anaconda folks
> > are not eager to add variations like this, but that is exactly what we
> > need: If you want to enforce product-specific policy in the installer,
> > it needs to be a product-specific installer.
> 
> You're assuming before asking.  With the structure of the installer now, we
> can look at changes like taking the password aspect and making it
> product-specific controllable by a number of different methods.  Our
> historic aim to end variant specifics in the installer was because the old
> code (and variants) lacked a way to assign owners to those product
> specifics, which meant that requests of the installer to be product specific
> meant we were asked to be the owners of those specifics.

Let me ask now, then: can we make the change to reject 'weak' passwords
specific to only those products that enable sshd by default, please ?

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test