F23 Self Contained Change: Standardized Passphrase Policy
by Jan Kurik
= Proposed Self Contained Change: Standardized Passphrase Policy =
https://fedoraproject.org/wiki/Changes/Standardized_passphrase_policy
Change owner(s):
* Kevin Fenzi <kevin at scrye dot com>
* David Cantrell <dcantrell at redhat dot com>
* Tomas Mraz <tmraz at redhat dot com>
Currently a number of places ask users to set passphrases/passwords. Some of them enforce some kind of rules for passphrases/passwords, others different rules. This change would create a common base policy for as many of these applications as possible, allowing for local users or products to override this base in cases they need to do so.
== Detailed Description ==
We should have a base passphrase/password policy for applications to use. This allows them all to be consistent and also provide our users with needed security. Additionally, we should make it possible for our users to adjust this base policy as they need depending on their use cases.
The applications involved in this change should be at least:
* anaconda - sets initial root and user passphrases/passwords.
* passwd - command line utility that changes passphrases/passwords.
* initial-setup - sets up users if they were not setup in anaconda.
* libpwquality - doesn't set passwords, but should be used in common for quality checking in a consistent manner.
We should provide a way for users or products to adjust this policy, and also a way to allow overriding it (if the policy allows).
== Scope ==
* Proposal owners: Will work with owners of these components to try and come up with a generic policy for passphrases/passwords and how to implement it, then get FESCo to approve this policy and then implement it.
* Other developers: Will need to adjust applications and config to use a common set of requirements that can be overriden in one place.
* Release engineering: None
* Policies and guidelines: Will need to be approved by FESCo and FPC (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
--
Jan Kuřík
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
8 years, 9 months
Docker base image naming for non-x86_64
by Adam Miller
Hello all,
There was recently a thread on the Fedora ARM mailing list[0]
about getting a Fedora ARM image into the official Docker Hub. That
discussion lead down the trail of how to best handle the naming for
all of this.
The current questions are either using Fedora's namespace and just
making a new image (using Fedora ARM as an example), this would be the
"FROM" line for a Dockerfile
FROM fedora/armhfp
Which would then contain all the standard tags for latest, rawhide, f22, etc.
Or alternatively, have each architecture maintain their own namespace
within the Hub which would look a little more like:
FROM fedora-arm
I'm personally a fan of the first option because it keeps things under
the Fedora umbrella and also allows for flexibility of aarch64, POWER,
etc as Docker supports more architectures. However the one thing I see
there that could be problematic is the possibility for users to be
confused if they don't search on the Docker Hub webUI and see the
associated documentation highlighting that the base image is for a
different architecture but instead just search from the docker command
line and end up with an image that won't run.
Looking forward to feedback on the topic.
Thanks,
-AdamM
[0] - https://lists.fedoraproject.org/pipermail/arm/2015-June/009526.html
8 years, 9 months
F23 System Wide Change: jQuery
by Jan Kurik
= Proposed System Wide Change: jQuery =
https://fedoraproject.org/wiki/Changes/jQuery
Change owner(s): T.C. Hollingsworth <tchollingsworth at gmail dot com>
jQuery is a fast, small, and feature-rich JavaScript library. It makes things like HTML document traversal and manipulation, event handling, animation, and Ajax much simpler with an easy-to-use API that works across a multitude of browsers. With a combination of versatility and extensibility, jQuery has changed the way that millions of people write JavaScript.
Traditionally, a copy of jQuery has been included with every web application that requires it. This change will migrate many of those applications to a shared system copy of jQuery. Both the 1.x branch of jQuery that supports Internet Explorer 6 and the 2.x branch of jQuery that only works with modern web browsers will be provided.
== Detailed Description ==
Traditionally, a copy of jQuery has been included with every web application that requires it. This change will migrate many of those applications to a shared system copy of jQuery.
The following packages are available in Fedora 21 and later and EPEL 6 and later:
* js-jquery - The latest version of the jQuery 2.x branch, suitable for web applications that are only compatible with modern web browsers that fully support modern web standards.
* js-jquery1 - The latest version of the jQuery 1.x branch, suitable for web applications that endeavor to be compatible with older web browsers such as Internet Explorer 6.
* js-jquery-migrate - The jQuery migrate plugin, which is a compatibility shim that enables web applications that depend on older versions of jQuery to work with the latest version, so that they can be ported away from old, unsupported jQuery versions that may potentially have security issues.
Some new packages are already beginning to use the system version of jQuery with little trouble, so for Fedora 23 we're going to open the doors to converting existing packages. We'll send announcements explaining how to unbundle existing packages. We'll also find all the packages we can that are bundling jQuery and inform maintainers about them, via e-mail only at this time. (We'll save the mass bug filing for F24 to allow maintainers to have a go at it voluntarily first. :-)
== Scope ==
* Migrating Web Applications
-- Web applications that depend on modern versions of jQuery will simply be ported to use the systemwide version instead,
-- Web applications that use older versions of jQuery (> 1.6.4 but <1.9) will be ported to use jquery-migrate and the systemwide version of jQuery. Packagers will be encouraged to work with upstream to migrate to the latest version of jQuery without jquery-migrate, since using this plugin re-enables misfeatures rightly removed from jQuery core that are XSS holes waiting to happen.
-- Maintainers of web applications that use extremely old versions of jQuery (< 1.6.4) will be strongly encouraged to work with upstream to migrate to the latest versions of jQuery and update their packages. However, current Fedora policy regarding bundled libraries permits these packages to be grandfathered in, so I am unable to force any action here.
-- Preliminary repoqueries have been performed to identify potentially affected packages, see the dependencies section for more details.
* Migrating documentation frameworks
-- Certain documentation frameworks, such as python-sphinx, ship copies of jQuery as well. These frameworks will be modified to use a symlink or other means so that they too can use the new systemwide versions.
* Release Engineering
-- No special attention required.
--
Jan Kuřík
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
8 years, 9 months
How to build one TeXLive subpackage for EPEL-7?
by Matěj Cepl
Hi,
I would like to build lilypond for EPEL-7, but unfortunately it
requires texlive-metapost which we don't have in the RHEL-7
texlive. Now, the question is how to build just one subpackage
(or any required other subpackages) from the monstrosity which
the current texlive? Anybody any suggestions?
Best,
Matěj
--
http://www.ceplovi.cz/matej/, Jabber: mcepl<at>ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC
Ty zlý dávaj’ ty hodný pryč. // Those evil ones put away those good ones.
-- Magda Ceplová
8 years, 9 months
Driver 'mmcblk' needs updating - please use bus_type methods
by Dario Lesca
On my Fedora 22 up to date (kernel 4.0.5-300.fc22.x86_64), when I
insert a SSD card I get this warning:
> giu 30 01:03:27 dodo.home.solinos.it kernel: mmc0: new high speed SDHC card at address 59b4
> giu 30 01:03:27 dodo.home.solinos.it kernel: Driver 'mmcblk' needs updating - please use bus_type methods
> giu 30 01:03:27 dodo.home.solinos.it kernel: mmcblk0: mmc0:59b4 00000 14.9 GiB
And after some time (dd if=img of=/dev/mmcblk0) I get many kernel error
like these:
> giu 30 01:32:14 dodo.home.solinos.it kernel: ------------[ cut here ]------------
> giu 30 01:32:14 dodo.home.solinos.it kernel: WARNING: CPU: 0 PID: 0 at drivers/mmc/host/sdhci.c:857 sdhci_send_command+0xa73/0xc50 [sd
> giu 30 01:32:14 dodo.home.solinos.it kernel: Modules linked in: mmc_block bnep bluetooth fuse xt_CHECKSUM iptable_mangle ipt_MASQUERAD
> giu 30 01:32:14 dodo.home.solinos.it kernel: parport_pc shpchp parport mei_me tpm mei dell_smo8800 nfsd auth_rpcgss nfs_acl lockd gra
> giu 30 01:32:14 dodo.home.solinos.it kernel: CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 4.0.5-300.fc22.x86_64 #1
> giu 30 01:32:14 dodo.home.solinos.it kernel: Hardware name: Dell Inc. Latitude E5520/03PH4G, BIOS A05 11/30/2011
> giu 30 01:32:14 dodo.home.solinos.it kernel: 0000000000000000 c244236c9fe8f15d ffff88022ec03d08 ffffffff817834f4
> giu 30 01:32:14 dodo.home.solinos.it kernel: 0000000000000000 0000000000000000 ffff88022ec03d48 ffffffff8109c66a
> giu 30 01:32:14 dodo.home.solinos.it kernel: ffff880224e7c4c0 ffff880224e7c4c0 ffff8801f12910f0 ffff8801f1291170
> giu 30 01:32:14 dodo.home.solinos.it kernel: Call Trace:
> giu 30 01:32:14 dodo.home.solinos.it kernel: <IRQ> [<ffffffff817834f4>] dump_stack+0x45/0x57
> .....
> giu 30 00:55:49 dodo.home.solinos.it kernel: DMA: Out of SW-IOMMU space for 65536 bytes at device 0000:09:00.1
> giu 30 00:55:49 dodo.home.solinos.it kernel: DMA: Out of SW-IOMMU space for 65536 bytes at device 0000:09:00.1
> giu 30 00:55:49 dodo.home.solinos.it kernel: ------------[ cut here ]------------
> giu 30 00:55:49 dodo.home.solinos.it kernel: WARNING: CPU: 0 PID: 10598 at drivers/mmc/host/sdhci.c:857 sdhci_send_command+0xa73/0xc50
> giu 30 00:55:49 dodo.home.solinos.it kernel: Modules linked in: uas usb_storage vfat fat mmc_block bnep bluetooth fuse xt_CHECKSUM ipt
> giu 30 00:55:49 dodo.home.solinos.it kernel: mei_me parport_pc wmi i2c_i801 mei tpm_tis parport tpm shpchp dell_smo8800 nfsd auth_rpc
> giu 30 00:55:49 dodo.home.solinos.it kernel: CPU: 0 PID: 10598 Comm: mmcqd/0 Tainted: G W 4.0.5-300.fc22.x86_64 #1
> giu 30 00:55:49 dodo.home.solinos.it kernel: Hardware name: Dell Inc. Latitude E5520/03PH4G, BIOS A05 11/30/2011
> giu 30 00:55:49 dodo.home.solinos.it kernel: 0000000000000000 00000000f78a99be ffff88022ec03d08 ffffffff817834f4
> giu 30 00:55:49 dodo.home.solinos.it kernel: 0000000000000000 0000000000000000 ffff88022ec03d48 ffffffff8109c66a
> giu 30 00:55:49 dodo.home.solinos.it kernel: ffff8802227de4c0 ffff8802227de4c0 ffff88021776b290 ffff88021776b310
> giu 30 00:55:49 dodo.home.solinos.it kernel: Call Trace:
The card written is unusable and I must reboot my notebook to use it
agains.
This problem is new for me (Update from f21 to 22), I have write with
this NB many card SD in the past.
If I usa another notebook with F21 the problem not happens and the card
is written good.
Some one have some suggest?
Many thanks
--
Dario Lesca
(inviato dal mio Linux Fedora 22 con Gnome 3.16)
8 years, 9 months
Checking the ABI of packages submitted to the updates-testing Fedora repository
by Dodji Seketeli
Hello,
Following up on the ABI checking topic raised in the "API Break
Detection" section near the end of the post
https://lists.fedoraproject.org/pipermail/server/2015-June/001904.html,
I'd like to summarize where we stand at the moment and what we plan do.
We discussed this topic on the #fedoral-devel IRC channel yesterday and
here is what stuck to my mind. Others are of course welcome to add what
I have forgotten and to correct me when I a wrong.
To start, we'd like to have an automated way to check the ABI
compatibility of binaries embedded in packages that are submitted to the
updates-testing repository. When an incompatible change[1] is detected,
the package will be prevented from auto-increasing it's karma count. I
guess a manual intervention will then be required to increase the karma
or a new package version needs to be submitted again.
Under the hood, the current informal plan seems to be to come up with a
Taskotron checking task, which, for a given package named P, will
compare the ABIs of the binaries embedded in P against their
counterparts in the latest known stable version of P that is present in
the stable repository. The result of the comparison shall be a report
showing the ABI difference of the offending binaries, if those changes
are deemed harmful or possibly harmful, from an ABI compatibility
standpoint.
At this moment, we do have a command line tool named "abidiff"[2] that
knows how to compare two shared library binaries and emits a report
about the differences in their ABI. That tool needs the debug info of
the binaries too. We are currently working on a tool named
"abipkgdiff"[3] that takes two RPMs and compares the shared library
binaries. That tool should be ready enough (hopefully) in the coming
days.
When the "abipkgdiff" command line tool is ready , I guess the plan is
to use it in a new Taskotron task that, when invoked on a given package,
gets the stable version of that package as well as the debuginfo
packages from koji, executes abipkgdiff to compare the package against
it's stable version and emits the resulting report.
So, that is the first "baby step" we talked about.
There are obviously going to be many other baby steps coming up, and
I'll write something about them a little bit later on this topic,
possibly in the wiki, rather. Needless to say, even the baby steps in
this note need to be refined, I guess we'll do that on the wiki some
where. But until then, I thought I'd drop this note to let you know
where we stand.
Thank you for reading so far.
[1]: A change in a the ABI of a shared library is considered
"compatible", if an application linked with the older version of the
library is still going to function reliably when executed against the
newer version of the library, without being re-linked. Otherwise, the
ABI change is considered "incompatible".
[2]: abidiff manual documentation can be consulted at
https://sourceware.org/libabigail/manual/abidiff.html
[3]: abipkgdiff is being hacked on by Sinny Kumari in a branch of the
upstream libabigail git repo at
https://sourceware.org/git/gitweb.cgi?p=libabigail.git;a=shortlog;h=refs/...
--
Dodji
8 years, 9 months
Thunderbird-38.0.1 integrates lightning? Very disturbing!!
by Joachim Backes
Hi dear developers,
after upgrading to tb-38.0.1, thunderbird-lightning-3.3-5.fc22.x86_64
has been obsoleted (as the formus are telling), but still the addons
manager of tb shows lightning as installed extension which can be
activated and removed.
Because I thougt that tb-lighning is now obsolete, I removed the
extension, but then I get rid totally from the calendars. So my
question: how t get the calendars running in TB without installing
lightning from the moz. extension pages?
Joachim Backes
--
Fedora release 22 (Twenty Two)
Kernel-4.0.7-300.fc22.x86_64
Joachim Backes <joachim.backes(a)rhrk.uni-kl.de>
https://www-user.rhrk.uni-kl.de/~backes
8 years, 9 months
[Test-Announce] Call for Fedora 23 Test Days
by Mike Ruckman
F23 is about to branch [0] and it's time we started thinking about what
we'd want to have a test day for. There are several changes accepted
already for F23, and more that have yet to be decided [1]. You can find
the list here:
http://fedoraproject.org/wiki/Releases/23/ChangeSet
Please take some time and look through the list and see if there's
anything you'd be interested in testing - or if there's something you
think should get some testing that isn't in the ChangeSet!
For those of you not familiar with test days, a test day is an
online event aimed at testing a specific feature of an upcoming Fedora
Release. By utilizing IRC for organization/coordination and a Wiki
page for instructions and results, test days are easy to organize.
Anyone can request to host a test day or request that the QA team help
you out with the organization of the test day. A test day can be ran
for any feature or area of a distribution that focused testing would be
useful for. More information on test days can be found here:
https://fedoraproject.org/wiki/QA/Test_Days .
To propose a test day, file a ticket on the QA Trac. A full
explanation can be found here:
https://fedoraproject.org/wiki/QA/Test_Days/Create . The SOP for
hosting a test day is here:
https://fedoraproject.org/wiki/QA/SOP_Test_Day_management .
Traditionally test days have been held on Thursdays, but if you'd prefer
to have it on another day that's fine too. We're pretty flexible, but
having plenty of lead time helps to get the word out. Just put in your
ticket the date or time-frame you'd like, and we'll figure it out from
there.
If you have any questions about test days or the process, please don't
hesitate to contact me or any other QA Team member in #fedora-qa on
Freenode or respond on the test list.
Thanks and happy testing!
[0] https://fedoraproject.org/wiki/Releases/23/Schedule
[1] https://fedorahosted.org/fesco/ticket/1445
--
// Mike
--
Fedora QA
freenode: roshi
http://roshi.fedorapeople.org
_______________________________________________
test-announce mailing list
test-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
8 years, 9 months