On Tue, 25 Oct 2011, Mario Ceresa wrote:
That's strange: the only two occasion I had a failed OTP were:
1) A configuration problem: (Yubikey not enabled, yubikey prefix not
correct, using unburned key)
2) In a two slot configuration, whenever I press the button too long
and it generates
On Thu, 20 Oct 2011, Nathan O. wrote:
slot 1: fedora OTP configured with fedora-burn-yubikey -u
slot 2: yubico OTP. Using the command line tool shipped with fedora
gave me some problems, so I used the one from yubico
On Thu, 13 Oct 2011, Tomas Mraz wrote:
And if this malicious DNS administrator controls the caching
nameserver you're using for DNS queries, he can present you ANY data
even 'valid' fake DNSSEC data.
This is not generally true. Resolver libraries can (and should, IMHO)
verify DNSSEC
On Thu, 13 Oct 2011, Tomas Mraz wrote:
Nope, you do not understand what the dependency is. Of course you depend
on the DNS to not be compromised to get the IP address of the host but
you still can verify the fingerprint on the first connection if you got
it by other means.
That scales as
On Thu, Oct 13, 2011 at 10:55:59PM -0500, Callum Lerwick wrote:
Its the only right way to do it. As a general rule, a private ssh key
should NEVER be transferred off the machine it was generated on.
Yeah, who needs backups of private keys anyways!
you have the same private key on more than
On Thu, 13 Oct 2011, Callum Lerwick wrote:
Yeah, who needs backups of private keys anyways!
We're talking about SSH keys here. There's no web of trust to lose.
Lose your keys? Generate new ones.
And contact my customers and what not to change it? Go past all the
servers i have access to with
On Wed, 12 Oct 2011, Kevin Fenzi wrote:
* DO verify ssh host keys via dnssec protected dns. ( .ssh/config:
VerifyHostKeyDNS yes)
https://bugzilla.redhat.com/show_bug.cgi?id=180277
https://bugzilla.redhat.com/show_bug.cgi?id=730558
You can't tell us to use this while at the same time refusing
On Wed, 12 Oct 2011, Adam Williamson wrote:
Reading between the lines of recent attacks, it seems likely that
private keys compromised in some of the attacks were used to perform
others. (No-one's come out and officially said this yet but it seems
pretty obvious from the subtext of some of
On Wed, 12 Oct 2011, Tomas Mraz wrote:
Except nobody says or said that DNS without DNSSEC leads to the
automatic connection with such setting.
I answered that multiple times, including today with a vast amount of screen
pasting
into https://bugzilla.redhat.com/show_bug.cgi?id=180277 to show
On Tue, 11 Oct 2011, Nathanael D. Noblet wrote:
As far as I know if you burn the key you will lose the ability to use
the yubikey's servers and I'm guessing coincidentally the lastpass as
well. I have seen that you are allowed to upload a new key to their
servers to restore its useability. So
On Thu, 22 Sep 2011, Dan Williams wrote:
But I'm not really familiar with unbound. Is it a long-running service?
Yes, It's a fully dnssec validating caching resolver. You start it at boot
and leave it running.
What does its config file look like? Does it re-read config data on
SIGHUP?
You
On Thu, 22 Sep 2011, Dan Williams wrote:
You properly talk to it via unbound-control, which uses SSL certs between
it and the daemon. No need to re-write config files or send it weirdo
signals.
Ok, this part mystifies me. I assume it just has a TCP socket listening
that you talk to it on?
On Wed, 21 Sep 2011, Adam Tkac wrote:
this is a great idea and work. We talked (inside Red Hat) about similar
approach how to secure the clients but this proposal is better, ready
for use, and I like it.
Great. Please test and give us feedback :)
The only one question for discussion is if
On Wed, 21 Sep 2011, Tomas Mraz wrote:
solve a part of the problem how can you even consider removing the
ability for disabling dnssec when implementing and deploying and running
dnssec increases the complexity times hundred and people and isp's alike
cant even implement and properly run a
On Sun, 18 Sep 2011, Nicolas Mailhot wrote:
We are trying to get DNSSEC validation on the end nodes. One way of doing
that is to run a caching resolver on every host, but that strains the
DNS infrastructure because all DNS caches would be circumvented.
However, there are many networks out
Hi developers of NM and Fedora,
We are trying to get DNSSEC validation on the end nodes. One way of doing
that is to run a caching resolver on every host, but that strains the
DNS infrastructure because all DNS caches would be circumvented. Since
DNSSEC data is signed, you can obtain it via
On Tue, 6 Sep 2011, Richard Shaw wrote:
Most of the packages I work with have very few patches so it's not all
that difficult, but there are a couple of packages I'm working with
that have a lot of patches and one of them has a very active upstream
(which is a good thing!) but that also means
On Wed, 24 Aug 2011, Ian Pilcher wrote:
On 08/22/2011 06:35 PM, Paul Wouters wrote:
If it could also not grab port 0.0.0.0:53 in the future, that would be
great. I'd like to work with whichever libvirt developer takes this
package on.
Are you talking about dnsmasq or the way that libvirt
On Thu, 25 Aug 2011, Tomas Mraz wrote:
3) I mostly don't need/want any DNS/DHCP in my bridged setup, but it still
configures and starts dnsmasq (at least on F14 using virt-manager)
(eg I have a /28 bridges to eth1 with static IPs, I don't want it)
On a non-bridged setup it listens
On Thu, 25 Aug 2011, Thomas Moschny wrote:
2011/8/25 Paul Wouters p...@xelerance.com:
Again, this is based on f14, not f15/f16. I am not sure how much this has
been
addressed. But if we want DNSSEC validation on the endnode, at the very least
127.0.0.1:53 needs to be left free.
Are you
On Thu, 25 Aug 2011, Daniel P. Berrange wrote:
libvirt's dnsmasq will never be grabbing any 127.0.0.1 address. It is
In my experiments it did not, and the issue instead was that the other
DNS server [1] wanted to grab port 53 on *all* interfaces.
Yeah, that is the normal problem people see.
On Mon, 22 Aug 2011, Stephen Gallagher wrote:
(Sent on behalf of jima, the former owner)
The dnsmasq package in Fedora has now been orphaned. This package is in
need of a new maintainer and should not be allowed to lapse, as it is a
critical component of the virtualization features.
It is
On Fri, 29 Jul 2011, Tore Anderson wrote:
There's two potential explanations for that that I'm aware of:
1) The «Require IPv4 for this connection to complete» NM setting is
unfortunately checked by default, see
https://bugzilla.redhat.com/show_bug.cgi?id=538499 and
On Tue, 12 Jul 2011, Bill Nottingham wrote:
The following packages are currently orphaned, or fail to build. If
you have a need for one of these packages, please pick them up.
This list has been fixed to properly show all orphaned packages. It's
a lot longer.
Orphan python-pydns
Orphan
On Tue, 5 Jul 2011, Misha Shnurapet wrote:
The backdoor payload is interesting. In response to a :) smiley face in the
FTP username, a TCP callback shell is attempted.
There is no obfuscation.
I have a question: how does that relate to our package building process, and
are GPG signatures
On Fri, 17 Jun 2011, Evandro Giovanini wrote:
I'm not really sure I get what you're asking for here. GNOME 3 does have
the classic (Win95-like) design installed by default and all you have
to do is enable fallback mode in order to use it.
1) I was not aware of classic mode, it was clearly not
On Fri, 17 Jun 2011, Rahul Sundaram wrote:
GNOME 3 menu has categories in the right as well but in any case, the
common apps are in the dash and using a keyboard with a search as you
type interface isn't the same as using bash. Let us not be dramatic.
With Everything missing, most of it
On Thu, 12 May 2011, Xose Vazquez Perez wrote:
On 03/19/2011 04:46 PM, Xose Vazquez Perez wrote:
Upstream maintainers believe 5.x is ready for distributions,
see thread:
http://gmplib.org/list-archives/gmp-discuss/2011-February/004526.html
5.0.1 was released ONE year ago, and no
On Wed, 27 Apr 2011, Chuck Anderson wrote:
On Thu, Apr 28, 2011 at 02:59:09AM +0200, Reindl Harald wrote:
because the same hostname can have A and AAA records
and the people commonly use ping (sysadmins) must be
able to decide what they will test?
Use -4 -or -6 parameters if you care to
On Mon, 21 Mar 2011, Yin Qiu wrote:
Have fun with your GSoC project!
I'll briefly talk about my understanding about the idea. In the spirit of
dividing the project into separate pieces, I suggest the final deliverables
include:
1) a script to help repositories that reside on nfs or http
This nonsense is still present in th el5 package. Can a provenpackager please
get
rid of it. Bug 522053 is even closed now
Paul
Preparing...### [100%]
1:tor-core ### [ 33%]
On Tue, 14 Dec 2010, Tomasz Torcz wrote:
We saw it includes /dev, /dev/shm etc. Is there any *reasonable* need
to mount sysfs somewhere else than /sys. Or /dev with mode other than 755?
Those all directories are mounted _identically_ on every Linux distribution
down here. Why pollute fstab
On Tue, 14 Dec 2010, Tomasz Torcz wrote:
Of course administrator can temporary override:
mount /dev/shm -o remount, nosuid
Or even have it stick after reboot, by droping in /etc/systemd/system/
following unit definition¹:
No.
You either follow what is in /etc/fstab, or you disallow it
On Tue, 14 Dec 2010, Bill Nottingham wrote:
It probably should be relnoted, sure.
A relnote is not a substitute for proper documentation, logging and man pages.
Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Mon, 29 Nov 2010, Toshio Kuratomi wrote:
* after a reboot, the application is able to startup and write to a directory
in /var/run and/or /var/lock.
All daemons should already be able to do that (meaning init scripts dealing
with non-existing directories)
* The sysadmin would like to be
On Tue, 30 Nov 2010, Tomasz Torcz wrote:
I would really like to avoid having THREE places to create directories
in /var/run and /var/lock, those being spec file, init scripts AND tmpfiles.d
Scratch the initscript. This would mean initscript would need to
contain multiple
On Wed, 24 Nov 2010, Toshio Kuratomi wrote:
And when are the files and dirs created? Only when the system is
booted?
Yes.
But then after installing an package that requires files to be created
by tmpfiles.d the system needs to be rebooted before it can be used. Or
will rpm call something
On Wed, 24 Nov 2010, Paul Howarth wrote:
Is that needed if the package init script deals with this already?
(eg xl2tpd will create /var/run/xl2tpd if it does not exist)
If the initscript already does it then that should be fine.
But Lennart prefers the tmpfiles.d approach as it's less
On Wed, 24 Nov 2010, Petr Lautrbach wrote:
- Many .spec files currently own subdirs of /var/run. These need to be
updated to %ghost those dirs only, so that the automatic removal of
these files/dirs on boot doesnt cause rpm to complain. The list of
packages
which own such
On Wed, 24 Nov 2010, Paul Howarth wrote:
This remark makes no sense? If they already needed ghosting, then the
mass-file should
be needed?
Files are directories are currently treated differently. The initscripts
clean out files from /var/lock and /var/run but leave directories alone.
So
On Wed, 24 Nov 2010, Lennart Poettering wrote:
BTW, regarding at and cron: what I was thinking of but never check
ehwther it is feasible is to make cron/at autostart a soon as some job
is scheduled. I.e. use .path trigger to check whether /etc/crontab and
user jobs exist, and start cron only
On Tue, 23 Nov 2010, Nicholas Miell wrote:
The spec page says it'll be better, but is very vague as to why.
Basically, I'm looking for a Doing this will keep $X kilobytes
permanently pinned in RAM (in the form of dentry and inode structs) and
$Y bytes in RAM or swap (in the form of file data
On Thu, 11 Nov 2010, Lennart Poettering wrote:
That way most distros would only have to install one getty implementation,
and can use it for both serial consoles and VCs.
Yes please.
Bonus points for anaconda configuring a working agetty login if the install
console was serial. That is, run
On Fri, 12 Nov 2010, Kevin Fenzi wrote:
* grub2 (no one is driving for this that I know of, but has some
advantages over our grub1 if someone is willing to run with it, although
it may be a lot of work to get it to where we need it).
I understood grub2 is much worse for serial console
On Fri, 8 Oct 2010, Dennis Gilmore wrote:
Even if you use your yubikey with yubicos servers. and auth against multiple
different providers your AES key is never exposed to to any of the places that
you auth to.
That is correct if different service providers auth the OTP against
yubicos
On Fri, 8 Oct 2010, Nathanael D. Noblet wrote:
On 10/07/2010 10:58 PM, Paul Wouters wrote:
One usage of yubikey I would like very much is as storage for the AES
encryption key for disk encryption. I'd prefer the disk crypto key to
not be on the disk at all, protected by just a passphrase
On Fri, 8 Oct 2010, Jesse Keating wrote:
Note that yubikeys are not (yet) usable for this. You cannot request the
AES key from it (AFAIK), only an OTP. And the OTP can also not be used to
unlock
an AES key on the harddisk because it is different for each activation.
Can't you use one of
On Thu, 7 Oct 2010, Mike McGrath wrote:
We also decided to allow yubikeys as an authentication option for the
larger community to some hosts and services like fedorapeople.org or
https://admin.fedoraproject.org/community/. When asked for a password,
just use your yubikey to generate a otp
On Thu, 7 Oct 2010, Mike McLean wrote:
I guess in a way it is like using the same password, but people might not be
thinking of that when they have a device on them that they use.
Wow, that's a serious weakness. Are we sure about this?
Author: pwouters
Update of /cvs/pkgs/rpms/perl-IO-LockedFile/EL-6
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv11395
Modified Files:
perl-IO-LockedFile.spec
Log Message:
* Wed Jul 07 2010 Paul Wouters p...@xelerance.com - 0.23-7
- Added missing dist tag
Index: perl-IO
On Thu, 24 Jun 2010, Tom spot Callaway wrote:
This is not possible as the ECC algorithm sources are removed from the
source tarball prior to adding it to the Fedora CVS.
Would it still be possible to have the define with a comment to grab the
source outside the CVS repo? I am just trying to
On Mon, 21 Jun 2010, Tomas Mraz wrote:
Looking at it more closely actually for the DNSSEC GOST R 34.10-2001 it
will not be possible to include it as it is elliptic curve based and all
the ECC code is removed from our Openssl source and build. I do not know
much about the ECC except it is a
On Mon, 21 Jun 2010, John Poelstra wrote:
Tue 06-Jul Tue 06-Jul Feature Submission Deadline One Week away
It would be good if we could get the issue of GOST support in openssl figured
out
in time for that deadline. Though I am not sure if that is possible. See my
other
msg to
On Mon, 21 Jun 2010, Tomas Mraz wrote:
I would be great if we could change the spec file to have a proper flag
to enable/disable GOST/ECC so that people can easilly rebuild with GOST
support if they need to (and it is legal for them). Would that be
legally possible?
This is not possible as
On Tue, 1 Jun 2010, Bruno Wolff III wrote:
Fixing init scripts and %post is now left in the state maintainer is too
busy to fix. In the past I already offered co-maintainership or taking
over the package due to my close relationship with upstream. It's a lame
excuse for leaving it in the
On Tue, 1 Jun 2010, Bruno Wolff III wrote:
Does FESCO know you'd be willing to become the maintainer?
I've definately talked to quite a few of them (online and in person) over
the years this has been going on. I even had a tor package made and
submitted it, but Enrico and my package crossed
On Mon, 31 May 2010, Ryan Rix wrote:
Airing out our dirty laundry for our users to see is not something that we
should allow or promote. I'm all for reporting errors, but b*tching to
users? No. I'm going to file a bug on this if someone else has not.
It's been filed many times, duplicated
On Sun, 30 May 2010, Matthew Miller wrote:
For the purposes of this complaint, I don't care. I do care that whenever
you install the package, it spits out this gem:
oouch... redhat-lsb is still broken. See the report
https://bugzilla.redhat.com/show_bug.cgi?id=522053
for details.
This
On Thu, 11 Mar 2010, Jesse Keating wrote:
https://fedoraproject.org/wiki/Stable_Release_Updates_Proposal
Here is the link. I'm going to start a new thread here.
# Stable releases should not be used for tracking upstream
version closely when this is likely to change the
On Thu, 11 Mar 2010, Seth Vidal wrote:
And it will be impossible for users running the non-sha256 bind to
communicate with the sha256 supporting arpa?
I guess I don't understand what do the users of the existing bind LOSE?
Is ARPA expecting everyone to upgrade to a sha256 supporting bind
On Thu, 4 Mar 2010, Enrico Scholz wrote:
[ two year tor insanity ]
It's been two years. I'm done with this discussion. I'm not spending more
time on the tor-enrico pacakge.
Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Wed, 3 Mar 2010, Enrico Scholz wrote:
The tor upstream has filed that as bug report as well.
... and understand my reasons not to activate logging
That is not true. It just decided not to pick a fight over that while
more pressing bugs required you to fix them.
ok; sorry that I thought
On Wed, 3 Mar 2010, Enrico Scholz wrote:
Upstream reports a logging bug.
??? You and Noa Resare were the only one who reported the non-logging as
a bug and some posts ago you said that you are not upstream. So, why do
you think that upstream reported a logging bug?
I pointed you to
On Tue, 2 Mar 2010, Bill Nottingham wrote:
Adam Williamson (awill...@redhat.com) said:
We should make a stand and drop it from Fedora until it's not made up of
bonghits and failure. (haha, yeah. thanks, here all week, etc)
I'm not quite sure why it needs separate lsb/upstart init scripts
On Tue, 2 Mar 2010, Bill Nottingham wrote:
Enrico Scholz (enrico.sch...@informatik.tu-chemnitz.de) said:
All the initscripts have huge and broken dependency chains.
E.g. assuming I would use the vanilla fedora 'initscripts' package, then
tor would still require[1] syslog, cpio, e2fsprogs,
On Tue, 2 Mar 2010, Enrico Scholz wrote:
It does not log anything because Enrico broke logging in tor package.
Not that this was the reason, but it is the upstream setup to have
logging disabled. Your comment is unrelated to this discussion because
logging can be done into a file and does
On Mon, 1 Mar 2010, Iain Arnell wrote:
Whilst cleaning up some recently adopted orphans, I discovered that
perl-Nmap-Parser has been tagged with the wrong license since August
2008. Upstream changed the license from GPLv2+ to MIT sometime back in
2007 and I've just corrected it in rawhide
On Fri, 26 Feb 2010, Chris Adams wrote:
EPEL has run this way for a while, and it doesn't seem to be a problem.
EPEL does not have a 6 month release cycle :)
Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Fri, 26 Feb 2010, Matthew Garrett wrote:
On Fri, Feb 26, 2010 at 08:15:43PM +0100, Till Maas wrote:
1) to fix a bug or add a feature the maintainer experienced/uses
If nobody is complaining about the bug, then fixing the bug can wait
until the next Fedora release.
Do you have the time
On Fri, 26 Feb 2010, Kevin Fenzi wrote:
A quicker way of seeing if a bug report was alread made, and more
quickly being able to report bugs then spending 15-30 with bugzilla
would help me in reporting more bugs. I like the automated crash
reporting, though I'm not sure where they go, as I
you can set both cflags and libs
with that, no patch required.
Best regards,
Wouter
On 02/24/2010 05:37 PM, Paul Wouters wrote:
Hi,
Fedora 13 will no longer implicitely link in certain libraries. For
a full description see:
https://fedoraproject.org/wiki/UnderstandingDSOLinkChange
On Thu, 11 Feb 2010, Paul W. Frields wrote:
Fedora 11: https://admin.fedoraproject.org/updates/F11/FEDORA-2010-1696
Fedora 12: https://admin.fedoraproject.org/updates/F12/FEDORA-2010-1748
For those interested in some more background information about the
chain of events on the dnssec-conf
Hi,
I just heard I might be put through the unresponsive maintainer process
in Fedora? I'm a little confused as I've never received emails on this,
and I'm always on irc and read fedora-devel and still perform very regular
package updates.
Can someone tell me what's going on, and forward me
On Fri, 29 Jan 2010, Paul Wouters wrote:
Subject: I am an unresponsive maintainer?
I just heard I might be put through the unresponsive maintainer process
in Fedora? I'm a little confused as I've never received emails on this,
and I'm always on irc and read fedora-devel and still perform
401 - 474 of 474 matches
Mail list logo
