rubygem-open4 license change
by Bohuslav Kabrda
Hi all,
due to license change in Ruby, I have updated the license of rubygem-open4 after clarification with its author.
Previous license was GPLv2+ or Ruby, current license is BSD or Ruby.
--
Regards,
Bohuslav "Slavek" Kabrda.
12 years, 2 months
Request for testers of dnssec-trigger (now in rawhide)
by Paul Wouters
Hi,
In our efforts to push DNSSEC to the enduser, we have packaged our
initial DNSSEC reconfiguration utility.
Basically, this makes it possible to use DNSSEC on your laptop, while
moving between networks of which some are "friendly" man in the middle
attacks on DNS via hotspots and sign-ons. Some steps are still awaiting
further network-manager integration. We hope to be able to hide almost
everything from the user, but the network manager integration is not yet
complete. But we would really like get more feedback on how well it
works in various alien and broken networks out there (especially wifi
and 3G/LTE)
First, to get some feedback on whether or not you are using DNSSEC and a
site is protected by DNSSEC, you should install the nic.cz Firefox
plugin that show DNSSEC information in the address bar:
http://www.dnssec-validator.cz/
Next, install dnssec-trigger (currently only in rawhide) but you can
grab a source rpm from here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3767834
Either reboot or start some services manually:
sudo systemctl start unbound-keygen.service
sudo systemctl start unbound.service
sudo systemctl start dnssec-triggerd-keygen.service
sudo systemctl start dnssec-triggerd.service
Then start the dnssec-trigger-applet from the Applications menu. A
(trust) anchor applet icon will now appear.
Now reconnect to your network so that NetworkManager receives DNS
servers via DHCP.
Browse to http://fedoraproject.org/ with firefox
If everything went well, you should see the green lock on the left
meaning that DNSSEC was used and proved that the DNS lookup for
fedopraproject.org was DNSSEC signed and used. There are other domains
you can use to test, perhaps most importantly at this point, paypal.com.
You can also run a manual test (dig +dnssec fedoraproject.org) and test
if the "ad" flag was set in the dig output.
If your icon is orange, it means your DHCP supplied DNS servers did not
perform DNSSEC. This should never happen in this setup, but would happen
if you only installed the firefox plugin and did not install and start
the unbound/dnssec-triggerd services.
When joining a new network, right-click the anchor and select
"re-probe". After a few seconds you can get some debug output by
right-clicking and selecting "show results".
What this does:
1) Perform various probes to see if the DHCP supplied DNS servers and
the network are DNSSEC capable. If so, reconfigure the system to use
these. We do not want applications to query these directly, as we do not
trust oursourcing DNSSEC validation to anyone but our own locally
running DNS server (unbound) as the connection between you and the ISP
DNS servers is not trusted, and attackers could rewrite DNS answers
unless your laptop itself confirms this with validation (it comes with
the DNS ROOT key preinstalled)
2) If these servers are broken, it will attempt to query authoritative
servers directly, bypassing the caching DNS servers from the ISP. We do
not do this per default because we do not want to destroy the internet's
DNS caching hierarchy.
3) If using authoritative servers directly fails (eg there is a bad
transparent port 53 proxy or firewall rule forcing use of the DHCP
offered (broken) DNS servers, there is an option to attempt DNS over TLS
and raw DNS over port 80. This is a method of last resort and works
surprisingly well (though slow). This is currently not yet enabled but
you can enable it manually in /etc/dnssec-trigger.conf. Once the nice
people of Fedora Hosted have added a few of these servers, we will
enable this fallback option via a package update.
4) if all of this fails, the user is prompted with a choice. Either go
into "cache only mode" where you cannot do any insecure lookups and are
only using the cached DNS answers you already had before you joined this
network, or you can go "insecure" in which case the local DNS server is
pulled aside (so it does not get poisoned with unvalidated results) and
you're all on your own in your very hostile network without DNSSEC (kind
of what you are likely using right now :) Exponential back-off attempts
run in the background to see if we can go back to a secure mode.
The Hot spot issue
Sometimes, you need to accept some "fake DNS" to get past the hotspot
portal. For this, the anchor also has an option. It will go into
"insecure" mode, and you can authenticate, pay or click "I acecpt your
terms". When you are done, you select "re-probe". (We cannot do this
automatically without risking to break your spoofed login portal page).
We are working on giving networkmanager a way to detect hotspots for you.
VPN and split DNS
If you connect to a VPN and you need a special DNS server to resolve
internal domains, you need to add an exception to
/etc/unbound/unbound.conf for now. The syntax is:
forward-zone:
name: "example.com"
forward-addr: 10.1.2.3
Future
Planned for the near future:
- Less user interaction, more network manager integration
- automatic hot spot detection
- network manager vpn plugin support for DNS forward-zone
- phasing out the applet in favour of native network-manager support
- validate TLS certificates via DNSSEC (IETF DANE support)
That's it, go break your DNS and let us know how it went!
Paul
12 years, 2 months
glibc policy chage?
by Michał Piotrowski
Hi,
I noticed that F17 is based on the latest stable glibc realease.
Previously development Fedora version was based on development glibc.
Was there a change of some Fedora glibc policy? If it is no
coincidence, but the new policy - many thanks for the change :)
--
Best regards,
Michal
http://eventhorizon.pl/
12 years, 2 months
Self Introduction
by Jamie Nguyen
Hello,
My name is Jamie Nguyen. I'm a student in the UK and part-time Linux
system administrator.
I am an active contributer to the TOMOYO Linux security project [1]
and provide a binary repository containing RPMS/SRPMS for TOMOYO Linux
kernels for Enterprise Linux 6 and Fedora 16 [2]. I also have
experience in tech documentation; I have edited the "How to create an
RPM" page in the Fedora wiki and have so far revamped the first half
[3] with a view to doing a more complete revamp soon.
I have one pending review request [4] for bashmount. I happen to be
the author of this command-line tool :-)
I would also be glad in the near future to co-maintain some or all of
the MPD stack of applications (e.g. libmpdclient, mpc, ncmpc, ncmpcpp,
sonata etc.). I have already posted a package review on the RPMFusion
bugzilla [5] for a very heavily revised mpd.spec that includes a
systemd service file (the mpd.spec file is much more complex than
bashmount.spec, so it may interest you to take a look).
Thanks everyone.
[1] http://tomoyo.sourceforge.jp/
[2] http://repo.tomoyolinux.co.uk/
[3] https://fedoraproject.org/wiki/Special:Contributions/Jamielinux
[4] https://bugzilla.redhat.com/show_bug.cgi?id=787858
[5] https://bugzilla.rpmfusion.org/show_bug.cgi?id=1944
12 years, 2 months
Does anyone still need to create legacy HFS filesystems?
by Matthew Garrett
There's various issues with the hfsplus utilities we ship at the moment,
including the fact that fsck.hfsplus crashes on 64-bit. I'd like to
update this to the latest upstream, but code to generate legacy HFS (ie,
pre-HFS+) filesystems has been dropped.
HFS+ was introduced in MacOS 8.1 in 1998, and support for writing or
creating HFS was removed in 10.6 in 2009. I can't think of any reason
why anyone would really need the ability to create HFS these days, but
wanted to get some feedback from others before dropping it. Does anyone
object?
--
Matthew Garrett | mjg59(a)srcf.ucam.org
12 years, 2 months
PIDA, pygtkhelpers, medit
by Jon Ciesla
PIDA, in f16 and beyond, has broken deps:
https://bugzilla.redhat.com/show_bug.cgi?id=754673
So to fix this, I need to update to the latest upstream:
https://bugzilla.redhat.com/show_bug.cgi?id=651853
But this release need python-flatland and pygtkhelpers. I got
python-flatland into Fedora.
pygtkhelpers is going to be a problem, as it bundles code from medit,
which in turn bundles gtksourceview:
https://bugzilla.redhat.com/show_bug.cgi?id=767185
The new pida release also apparently bundles code from medit.
I've torn out enough hair trying to unbundle gtksourceview from medit,
so I'm retiring PIDA and closing the pygtkhelpers review.
I anyone cares sufficiently about PIDA to see this through, you are
welcome to do so. :)
-J
--
in your fear, seek only peace
in your fear, seek only love
-d. bowie
12 years, 2 months
[Test-Announce] Announcing 389 Directory Server version 1.2.10 Release Candidate 1 Testing
by Rich Megginson
The 389 Project team is pleased to announce the release of
389-ds-base-1.2.10.rc1. No new features were added between alpha 8 and
rc1, just many bug fixes. There are also 389-adminutil, 389-admin, and
389-dsgw packages in Testing.
NEW: EL6 support
Beginning with RHEL 6.2, the 389-ds-base package is included in the base
OS. Therefore, the 389-ds-base package can no longer be provided via
EPEL, due to RHEL/EPEL packaging restrictions.
However, the 389 Project will still make the full 389-ds-base package
available via http://repos.fedorapeople.org/repos/rmeggins/389-ds-base.
See http://directory.fedoraproject.org/wiki/Download for more information.
NEW: Issue Tracking System
We have moved our ticket tracking system from the Red Hat Bugzilla
https://bugzilla.redhat.com/enter_bug.cgi?product=389 to our Fedora
Hosted Trac https://fedorahosted.org/389. All of the old 389 bugs have
been copied to Trac. All new bugs, feature requests, and tasks should be
entered in Trac
NEW: Plugin Authors
WARNING: Plugins should be made transaction aware so that they can be
called from within a backend pre/post transaction plugin. Otherwise,
attempting to perform an internal operation will cause a deadlock. See
http://directory.fedoraproject.org/wiki/Plugins
Installation
yum install --enablerepo=updates-testing 389-ds
# or for EPEL
yum install --enablerepo=epel-testing
[--enablerepo=epel-testing-389-ds-base] 389-ds
setup-ds-admin.pl
Upgrade
yum upgrade --enablerepo=updates-testing 389-ds-base
idm-console-framework 389-admin 389-ds-console 389-admin-console
389-dsgw 389-adminutil
# or for EPEL
yum upgrade --enablerepo=epel-testing
[--enablerepo=epel-testing-389-ds-base] 389-ds-base
idm-console-framework 389-admin 389-ds-console 389-admin-console
389-dsgw 389-adminutil
setup-ds-admin.pl -u
How to Give Feedback
The best way to provide feedback is via the Fedora Update system.
* Go to https://admin.fedoraproject.org/updates
* In the Search box in the upper right hand corner, type in the name of
the package
* In the list, find the version and release you are using (if you're not
sure, use rpm -qi <package name> on your system) and click on the release
* On the page for the update, scroll down to "Add a comment" and provide
your input
Or just send us an email to 389-users(a)lists.fedoraproject.org
Reporting Issues
https://fedorahosted.org/389
More Information
* Release Notes - http://port389.org/wiki/Release_Notes
* Install_Guide - http://port389.org/wiki/Install_Guide
* Download - http://port389.org/wiki/Download
_______________________________________________
test-announce mailing list
test-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
12 years, 2 months
Fedora 17 Feature Freeze is TOMORROW, February 7.
by Robyn Bergeron
A friendly reminder as we move towards a miraculous, beefy release:
* Feature freeze is tomorrow, February 7, 2012. At this point, all
accepted features should be substantially complete, and testable.
Additionally, if a feature is to be enabled by default, it must be so
enabled at Feature Freeze.
https://fedoraproject.org/wiki/Feature_Freeze_Policy
https://fedoraproject.org/wiki/Features/Policy/Milestones#Feature_Freeze
If you are a FEATURE OWNER:
* The percentage of completion on your feature's wiki page should
reflect your current progress. Feature pages should be updated *at
least* monthly.
https://fedoraproject.org/wiki/Features/Policy/Status
* Features which do not appear to be substantially complete will be sent
to FESCo for review as to whether or not they should continue to be
listed as a release feature. Your feature's wiki page status and
indication of progress is what determines whether or not it will be sent
to FESCo.
Please, for the love of Beefy, UPDATE YOUR PAGES. There are 62 features
(!!!!) currently slated for F17. Updating your feature page's completion
percentage, along with the date that you updated your page, prevents me
from having to relentlessly beg you all individually via e-mail to do
the same thing. :)
If you have questions, concerns, flames, or winning lottery tickets
which will prevent you from completing your feature, please don't
hesitate to contact me.
-Robyn
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
12 years, 2 months