dual sites yet. OCSP must-staple seems promising.
>
> Of course, we can't have any of these nice features in GNOME unless
> somebody wants to pay for their implementation. (If so, get in touch
> please.)
For the record, and all this can be solved by DNSSEC + DANE. See RFC 669
about
>> being at the cutting edge and that's where we should focus our limited
>> resources, even for cloud images.
>>
>> If people want cloud images with older software versions than are in the
>> current supported Fedora, they should be looking for cloud images from
>> CentOS/RHEL instead.
All EOL software should die by a violent death.
We have enough nightmares caused by buggy software which is not-yet EOL,
please do not add another pile of ...
--
Petr Spacek @ Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
nd from the KDE page.
> It's reasonably easy to find if you know what to look for on
> <https://getfedora.org/en/workstation/download/>.
Eh, you *should not* need to know where to look. If you know where to look you
go to FTP server directly ... Landing page
On 22.7.2014 17:16, Stephen John Smoogen wrote:
On 22 July 2014 09:05, Florian Weimer wrote:
On 07/22/2014 04:08 PM, Miloslav Trmač wrote:
The current plan is to not ship v6 in F21, and there are no agreed plans
to ship it in any future release either. See https://fedorahosted.org/
fesco/ti
On 1.10.2014 15:12, Nikos Mavrogiannopoulos wrote:
On Wed, 2014-10-01 at 08:33 -0400, Matthew Miller wrote:
On Wed, Oct 01, 2014 at 08:52:03AM +0300, Jonathan Dieter wrote:
The havege functions in the polarssl package are currently disabled
in the Fedora package. Newer releases of dolphin-emu,
On 8.10.2014 23:04, Haïkel wrote:
2014-10-08 20:31 GMT+02:00 Kevin Fenzi :
Greetings.
This F21 change:
http://fedoraproject.org//wiki/Changes/RPM-4.12
has brought us 'weak dependencies', namely:
Recommends, Suggests, Supplements and Enhances
Rpm in f21 and rawhide sees these in spec files an
On 9.10.2014 09:27, Jan Zelený wrote:
On 9. 10. 2014 at 08:57:42, Ralf Corsepius wrote:
On 10/09/2014 08:41 AM, Petr Spacek wrote:
On 8.10.2014 23:04, Haïkel wrote:
2014-10-08 20:31 GMT+02:00 Kevin Fenzi :
Greetings.
This F21 change:
http://fedoraproject.org//wiki/Changes/RPM-4.12
has
> which would also replace/be called by libuser. I’m not sure what is the
> implementation status of this effort.
I would advise you to discuss this on freeipa-de...@redhat.com mailing list,
FreeIPA and SSSD gurus are watching that list.
--
Petr Spacek @ Red Hat
--
devel mailing list
d
view flags in patches while closing a bug (by marking
>> them as reviewed, as refused, by dropping the review=? flags, or
>> perhaps by saking).
>
> The mails do not just cover patch review. They cover the 'needinfo'
> state as well: you get a reminder for any bug
thub.com/rpm-software-management/dnf-plugins-core/pull/47
but IMHO the fix was never released.
--
Petr Spacek @ Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On 7.4.2015 17:47, Petr Spacek wrote:
> On 7.4.2015 14:47, Jan Kratochvil wrote:
>> The current problem is that the suggestion GDB makes will not work anyway due
>> to:
>> dnf debuginfo-install does not accept NVRA
>> https://bugzilla.redhat.com/show_bu
rd (for instance) knows nothing about this… it just
>> eventually drops the connection because that address becomes unreachable (or
>> points a new host with no knowledge of this TCP connection and it promptly
>> RESETs). TB then tries to reopen a connection… I’v
ale data on clients, go and lower TTL to 1 second.
Lowering TTL should work for all clients, no matter if they have local cache
or not, i.e. including Windows/OSX.
Hopefully this shows that problem is not *technically* caused by caching on
clients but by inappropriate TTL settings in zones. As a network
administrator, you have the power to fix that centrally, without a need to
touch every single client.
I hope this helps.
--
Petr Spacek @ Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On 3.6.2015 10:58, Reindl Harald wrote:
>
> Am 03.06.2015 um 09:14 schrieb Petr Spacek:
>>> so with setup a dns cache on each and every machine you fuckup your network
>>> because you introduce the same negative TTL caching affecting OSX clients
>>> for
>>
has some caching mechanisms intended to help against
> that (but I'm not sure how reliable they are in preventing the issue,
> e.g. if you use a web proxy).
--
Petr Spacek @ Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On 3.6.2015 13:45, Reindl Harald wrote:
>
> Am 03.06.2015 um 13:39 schrieb Petr Spacek:
>> On 3.6.2015 10:58, Reindl Harald wrote:
>>>
>>> Am 03.06.2015 um 09:14 schrieb Petr Spacek:
>>>>> so with setup a dns cache on each and every machine you
quite unresponsive about this. As a result, we are not going to
declare anything to be 'trusted' in Fedora 23.
For now apps should not make any assumptions about resolver trustworthiness
(as they did for decades).
--
Petr Spacek @ Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
st or we are in Docker
container and we trust the host and so on.
In this case we trust to the result of validation indicated by AD bit.
Application will receive the answer marked as trusted if the resolver tells us
to do so by AD bit in the DNS reply.
Please read the post on Glibc mailing lis
scenario should work fine. Generally we need to get all tools to push the
DNS servers to NM (so somewhere else) so the information is available via
(e.g.) NM API.
That is ideal case which would allow us to centralize DNSSEC handling on one
place in dnssec-triggerd.
--
Petr Spacek @ Red Hat
--
devel m
On 12.6.2015 18:53, Dan Williams wrote:
> On Fri, 2015-06-12 at 17:10 +0200, Petr Spacek wrote:
>>> On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
>>>> On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
>>>>> decision needs to then be ma
is the source of information tied to the UI?
I suspect that networkd and others might not be very happy if the
NetworkManager has to be available just to pass the information from whatever
tool doing the actual job to the UI.
Could you please explain how can we do that in environments without
NetworkManager?
--
Petr Spacek @ Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
ains /bin before /usr/bin. Try to
change the order and rebuild the package.
Apparently Koji does not have this problem, please do not ask me why :-)
Petr Spacek @ Red Hat
> Also, can someone please confirm that I correctly took care of
> obsoleting the mercurial-emacs{-el} as p
On 30.6.2015 13:53, Bastien Nocera wrote:
>
>
> - Original Message -
>> On 30.06.2015 11:24, Tomas Hozza wrote:
>
>>> It means that the site of your bank you are on may not be provided the
>>> actual host you should be connected to, but instead by some attacker's.
>>> The insecure mode m
On 12.4.2014 17:25, Reindl Harald wrote:
Am 12.04.2014 17:11, schrieb Paul Wouters:
On Sat, 12 Apr 2014, Reindl Harald wrote:
"we" should not do anything - because "we" don't have a clue about the
network of the enduser
We know and handle a lot more than you think already using unbound with
Hello list,
I'm trying to rebuild bind-9.9.4-12.P2.fc20.src.rpm with
CFLAGS="$CFLAGS $RPM_OPT_FLAGS -O0 -ggdb".
I did the simplest possible thing - edited the original spec file (see
spec.diff) and built the package:
$ rpmbuild -ba bind.spec
The package builds and BIND itself seems to work. T
On 25.4.2014 16:28, Reindl Harald wrote:
Am 25.04.2014 16:10, schrieb Petr Spacek:
I'm trying to rebuild bind-9.9.4-12.P2.fc20.src.rpm with
CFLAGS="$CFLAGS $RPM_OPT_FLAGS -O0 -ggdb".
I did the simplest possible thing - edited the original spec file (see
spec.diff) and bu
On 25.4.2014 16:50, Reindl Harald wrote:
Am 25.04.2014 16:43, schrieb Petr Spacek:
On 25.4.2014 16:28, Reindl Harald wrote:
Am 25.04.2014 16:10, schrieb Petr Spacek:
I'm trying to rebuild bind-9.9.4-12.P2.fc20.src.rpm with
CFLAGS="$CFLAGS $RPM_OPT_FLAGS -O0 -ggdb".
I d
On 25.4.2014 18:19, Simo Sorce wrote:
On Fri, 2014-04-25 at 09:56 -0600, Pete Zaitcev wrote:
On Thu, 10 Apr 2014 10:41:54 -0400
Chuck Anderson wrote:
[...] We need an independent,
system-wide DNS cache, and always point resolv.conf to 127.0.0.1 to
solve this fundamental design problem with h
On 25.4.2014 20:03, Adam Jackson wrote:
Maybe think
about how to diagnose what's going wrong and fix the bug instead of
philosophizing.
It seems that
/usr/lib/rpm/find-debuginfo.sh
experts don't read this thread so I have filled bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1091989
--
Petr^2
On 29.4.2014 17:27, Colin Walters wrote:
[ Dropping devel-announce ]
On Tue, Apr 29, 2014 at 11:15 AM, Alexander Larsson wrote:
Not sure how to fix something like that though...
I think in both cases (host and container) it would be best if the local
resolver offered a local-only API (e.g.
On 30.4.2014 15:29, Simo Sorce wrote:
On Wed, 2014-04-30 at 08:49 +0200, Alexander Larsson wrote:
On tis, 2014-04-29 at 11:24 -0400, Simo Sorce wrote:
On Tue, 2014-04-29 at 17:15 +0200, Alexander Larsson wrote:
On tis, 2014-04-29 at 14:15 +0200, Jaroslav Reznik wrote:
= Proposed System Wide C
On 10.6.2014 14:16, Martin Gieseking wrote:
Hi,
I've tried to fix the broken zorba package in rawhide for a couple of weeks
now but, unfortunately, without much success. The upstream developers don't
seem to be able to find the cause for the issue either.
The problem is that the package fails t
On 10.6.2014 21:47, Martin Gieseking wrote:
Am 10.06.2014 20:44, schrieb Jerry James:
Here's the first problem pointed out by valgrind:
- class Store (src/store/naive/store.h) has a public member "zstring theEmptyNs"
- that object is set to a string that is also added to "StringPool
*theNamespac
On 12.6.2014 16:16, Miloslav Trmač wrote:
2014-06-12 9:30 GMT+02:00 Jan Zelený :
It boils down to this: someone is going to be inconvenienced. I argue
it's better to inconvenience the minority with special 'yum' needs by
making them use the 'yum-old' alias, rather than inconveniencing the
major
On 13.6.2014 14:58, Reindl Harald wrote:
Am 13.06.2014 14:53, schrieb Jan Zelený:
That being said, the reason for not renaming dnf to yum is that renaming this
project to yum will do nothing else than to confuse its users, as they will
think this is still yum and they should expect from dnf it
On 16.6.2014 17:06, drago01 wrote:
On Mon, Jun 16, 2014 at 4:53 PM, Matthew Miller
wrote:
On Mon, Jun 16, 2014 at 09:11:43AM -0500, Jeffrey Ollie wrote:
Been using yum-cron for years with good results.
If yum is being phased out, I'll want a dnf-cron replacement
Already exists:
$ rpm -ql dnf
completely unnecessary
> thing to do. Perhaps at some point, we could do this by offering a
> voluntary field for GitHub username, but it's certainly not essential to
> using GitHub to enable pull-requests.
>
> Of course, Fedora doesn't have to do it the way the ASF did, but
ions I have selected in my spec
> file appropriate for a backup server?
Generally principle of least privileges is okay, so I agree with your proposal
in general.
On the other hand I have to ask if the server must be running under root?
Shoudn't it run under a dedicated user, e.g. '
ble proposal to me.
--
Petr Spacek @ Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
7;t see any problem
> here, and I think updates (especially bugfixes) cannot be frequent enough.
+1 again. If you are not comfortable with updating e.g. every day, just
schedule the cron job to do it weekly/monthly instead of daily. It is
end-user's choice, there is not need to delay updates
d IPv6.
Apparently this is not Fedora-specific in any way because ArchLinux says the
same:
https://wiki.archlinux.org/index.php/IPv6#Disable_IPv6
"net.ipv6.conf.all.disable_ipv6=1" is good enough and should not have negative
side-effects of "ipv6.disable=1".
Having said that, I'
git repositories normally use '/' to separate namespaces, so i'd propose
>
> $ fedpkg clone containers/cockpit
>
> and maybe add support for
>
> $ fedpkg clone srpms/cockpit
>
> at the same time.
>
> This has the added benefit that cgit will automatic
WA
>> (PST8PDT)
>>
>>
> Why not also split out the systemd-network stuff? On most of our spins for
> Fedora releases, we don't even use it. The only product that does is Fedora
> Cloud (and maybe Fedora Atomic, too). It may not necessarily be a big chunk
> of code
install python python2-dnf
Maybe we can get a patch to ansible which prints a useful hint when Python 2
interpreter is not found on the target system?
I mean something like:
"Huh, there is no Python 2 on the system .
Please use gather_facts: False & raw module to install Python 2 packag
On 1.12.2015 08:20, Dan Book wrote:
> I have run into this before and it was very confusing, it really should be
> a separate command from remove for when you actually want to remove what
> dnf thinks is now "unused".
Maybe it would help if these auto-removed packages are clearly marked as such
in
on or
> update package delivery.)
When you are at it, would it be possible to sign repo metadata too, so we can
have repo_gpgcheck enabled for official repos?
--
Petr Spacek @ Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
On 1.12.2015 13:25, Panu Matilainen wrote:
> On 12/01/2015 10:02 AM, Petr Spacek wrote:
>> On 1.12.2015 08:20, Dan Book wrote:
>>> I have run into this before and it was very confusing, it really should be
>>> a separate command from remove for when you actually want to
ound dnssec-trigger actually done that in previous versions. Have you
tried it?
--
Petr Spacek @ Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
ee (like home.lennart.me) is unsigned. If the sub-tree is unsigned the
query will be re-send to local servers and returned to the client.
The assumption here is that if your domain is signed you have enough wisdom so
use DNSSEC-enabled resolvers in your network. If the domain is not signed we
wi
On 8.12.2015 10:34, Reindl Harald wrote:
>
>
> Am 08.12.2015 um 10:25 schrieb Petr Spacek:
>> On 8.12.2015 09:41, Gerd Hoffmann wrote:
>>>Hi,
>>>
>>>> Start moving away from
>>>> split DNS because that's going to be very hard to
;
> Make sense?
It certainly makes sense, and if read
https://fedoraproject.org/w/index.php?title=Changes/Default_Local_DNS_Resolver
and pages linked from
https://fedoraproject.org/w/index.php?title=Changes/Default_Local_DNS_Resolver#Documentation
you will find yourself that that is basically wha
another.rpm
> https://koji.fp.o/update-/path-to-yet-another.rpm
>
> After that go to https://bodhi.fp.o/update-/ to leave karma.
> """
I like this idea!
> dnf will skip packages that are not already installed with 'upgrade'.
> Since t
is the bit special
> requirements of rpm where you want to have non privileged readers that
> must not have any write access - which is required for most databases
> for locking.
I'm curious! Would it be possible to elaborate on reasons why no existing DB
was good enough for RPM?
Amazon bought box. TLD
[1].
"gateway." (as any other single-label name) can face the same faith one day,
when somebody decides to spend $$$ and buy it. Training anyone to rely on
"gateway" or any other single-label name is a bad idea.
"gateway.local." is okay, because
ork, yes. On the other hand, it
is clearly possible because SQLite was ported to LMDB as proof-of-concept, and
was actually faster than original implementation. See the README here:
https://github.com/LMDB/sqlightning
--
Petr Spacek @ Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
admin/lists/389-users.lists.fedoraproject.org/
--
Petr Spacek @ Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
On 25.11.2014 18:25, Simo Sorce wrote:
> On Tue, 25 Nov 2014 17:05:59 + (UTC)
> P J P wrote:
>
>> Hi,
>>
>>> On Tuesday, 25 November 2014 10:00 PM, Gabriel Ramirez wrote:
>>> I have a server which only runs several VM's with specific
>>> services, no need user accounts in the host or in th
On 9.12.2014 18:28, Radek Holy wrote:
> Dear users of YUM and DNF,
>
> I'm writing to you regarding a request for your feedback. I would be very
> grateful if you could send me a brief description of how you use YUM or DNF
> currently or how would you like to use it. I am particularly interested
On 10.12.2014 10:14, Petr Spacek wrote:
> On 9.12.2014 18:28, Radek Holy wrote:
>> Dear users of YUM and DNF,
>>
>> I'm writing to you regarding a request for your feedback. I would be very
>> grateful if you could send me a brief description of how you use YUM o
On 5.1.2015 15:57, Bastien Nocera wrote:
> - Original Message -
>> Björn Persson wrote:
>>> I bet! I worry that the questions would quickly become annoying. But if
>>> ports are going to be blocked by default, then there needs to be some
>>> way for non-sysadmin users to open them.
>>
>> No
On 6.1.2015 16:20, Nikos Mavrogiannopoulos wrote:
> Hello,
> I've created a transition tracker to system-wide crypto policy at:
> https://bugzilla.redhat.com/show_bug.cgi?id=1179209
>
> Currently it contains bugs filled against openssl and gnutls
> applications in Fedora. If you use some applicat
On 8.1.2015 14:56, Jan Staněk wrote:
> Hi guys,
> as the new BerkeleyDB 6.x has a more restrictive license than the
> previous versions (AGPLv3 vs. LGPLv2), and due to that many projects
> cannot use it, perhaps it is time to get rid of it from Fedora for good
> - or at least trim down the list of
On 15.1.2015 23:13, Nicolas Chauvet wrote:
> 2015-01-15 20:18 GMT+01:00 Orion Poplawski :
>
>> On 01/15/2015 04:20 AM, Ralf Corsepius wrote:
>>> On 01/14/2015 03:10 AM, Orion Poplawski wrote:
On 01/12/2015 06:08 AM, Vít Ondruch wrote:
> Dear Fedora developers,
>
> I'd like to coll
s include surprises like a
state-controlled CA which never issued public facing certificate etc.)
More importantly, this spoofed cert is easily usable for very targeted attacks
(e.g. to a single TLS connection) and is extremely hard to detect by
unsuspecting client.
See https://www.eff.org/observa
h.
>
> I think we added the Crawl-delay several years ago when we were having
> storage issues. We could definitely try removing it and see if things
> improve.
Yes please. We definitely should get archives indexed by search engines!
--
Petr Spacek @ Red Hat
--
devel mailing list
t/msg07227.html
Brave souls willing to standards-work related to PGP keyring formats are more
than welcome!
Petr Spacek @ Red Hat
> Everyone[*] who added a GPG keyid in FAS has their key published now
> using the OPENPGPKEY specification. You can obtain a key using the
> openpgpkey com
On 29.1.2015 15:27, Paul Wouters wrote:
> On Thu, 29 Jan 2015, Petr Spacek wrote:
>
>>> Fedora is probably the First to use OPENPGPKEY at a large scale.
>>>
>>> https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-01
>>
>> Paul, thank you for d
aration process:
Check if all bundling exception bugs opened in Fedora < N are closed. If not,
remove affected components which did not comply from ditro.
This will result in some fancy policy like 'no cross-SRPM dependencies on
components with bundled libraries are allowed or something similar'. Maybe
these packages with temporary bundling exception can be in separate
'fedora-pkg-candidate' repo?
This basically limits number of packages with bundled libraries in one
release. It is an attempt to balance:
- Headache caused by security issue in a library.
- Time needed to get new packages to Fedora.
- Incentive for unbundling.
Personally I consider point "Time needed to get new packages to Fedora." to
have major importance. The fact that the package is in repo/release gives you
(or at least me :-) great motivation to spend more time on it and possibly
work on library unbundling.
The time-bounded nature of the exception protects distro from becoming the
same mess as Windows with indefinite DLL bundling.
--
Petr Spacek @ Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
ated registry.
What RFC says that single-label names are 'special'?
In what sense 'special'?
How do you differentiate arbitrary 'single-label' from TLD in DNS?
Answers to these questions need backing from standards because all parties
doing name re
rs to hear what is the best solution/workaround for this.
--
Petr Spacek @ Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
atch', sorry. Apparently BIND is using
-fno-delete-null-pointer-checks from GCC 4.9 times.
Anyway, thank you for your input, I will find my way how to hack around it.
[1] http://www.cvedetails.com/product/144/ISC-Bind.html?vendor_id=64
--
Petr Spacek @ Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
e _warnings_ for a new set of issues, and -Werror enabled are
> going to FTBFS in masses.
>
> In other words: WARNINGS are warnings and not errors for a reason.
In this case the warning which was turned into error saved us asses because
the code would behave differently under too aggres
on "if (this)" checks.
>
> That switch allows to work around buggy programs, at the cost of optimizing
> them less, yes. In any case, such programs should be fixed, this must be
> always non-NULL, methods can't be called on NULL pointers.
Could you elaborate on this, p
On 19.2.2016 13:08, Marek Polacek wrote:
> On Fri, Feb 19, 2016 at 01:04:04PM +0100, Petr Spacek wrote:
>> On 19.2.2016 08:50, Jakub Jelinek wrote:
>>> On Fri, Feb 19, 2016 at 03:12:29AM +0100, Kevin Kofler wrote:
>>>> Jakub Jelinek wrote:
>>>>>
On 19.2.2016 13:30, Jonathan Wakely wrote:
> On 19/02/16 10:49 +0100, Petr Spacek wrote:
>> The thing is that some developers (e.g. me and ISC :-)) do not think that
>> assert() should be used only in debug builds.
>>
>> E.g. BIND itself is written in "Design by
ing a list suitable for
kickstart from package list from a running system.
--
Petr Spacek @ Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
,rc1,d,etc}." for SysV init scirpt locations
> was. And it would encourage the sort of randomization of default path
> to the .repo files that we saw for SysV init scripts, which could get
> pretty confusing.
+1
The Change Page did not even try to weight pros and cons. IMHO cons (as
described above) are worse that living with original name, which is
well-known, well-documented, and relied on.
--
Petr Spacek @ Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
ext "(note that adherence to the system-wide policies is work
> in progress for NSS libraries)" must be removed
> - The text "Currently the policies are restricted to applications
> using GnuTLS and OpenSSL" must be changed to include NSS.
>
> * Tra
On 11.11.2016 19:25, Japheth Cleaver wrote:
> On 11/11/2016 9:08 AM, Lennart Poettering wrote:
>> I still believe we should stick to a generic hostname by default,
>> (though I'd rather use "localhost" than "localhost.localdomain" in
>> order to drop the redhatism that "localdomain" is), and make t
le descriptor
2. call seteuid()
3. pass the file descriptor to the new process
I'm not saying that you need to do exactly this in case of elfutils but it
should work in the general case.
--
Petr Spacek @ Red Hat
___
devel mailing lis
in order to avoid running "dwfl_linux_proc_find_elf" function under root?
I'm not aware of any but maybe someone else on the list is.
The best would be to fix this upstream in elfutils.
--
Petr Spacek @ Red Hat
___
devel mailing list --
ndom password and never type it,
you can retrieve keytab for your account. The keytab file can contain e.g.
random 256 bit AES key so you will as safe as you can, assuming no attacker
can gain access to that file (which you assume already).
In Kerberized world this is usually
82 matches
Mail list logo
