On 09/07/15 12:39, Miloslav Trmač wrote:
Protected multilib versions: polkit-0.113-1.fc21.x86_64 !=
polkit-0.112-7.fc21.1.i686
This is due to polkit splitting out a polkit-libs package between those
two versions. This makes it only include the polkit-libs package
instead
On Wed, 8 Jul 2015 21:30:40 +0200
Reindl Harald h.rei...@thelounge.net wrote:
...snip...
Protected multilib versions: polkit-0.113-1.fc21.x86_64 !=
polkit-0.112-7.fc21.1.i686
This is due to polkit splitting out a polkit-libs package between those
two versions. This makes it
On Fri, Jun 26, 2015 at 2:36 PM, Christian Dersch lupi...@mailbox.org
wrote:
Additional info: Of course an Astronomy Tools group is a nice idea too!
But it doesn't replace the Spin as the download, boot and try it idea
doesn't work without a spin.
A possible work around:
It's possible
VPNs... done like 2 years ago. From what we discussed the connectivity
checking is not really perfect in NM, since it assumes that DHCP
provided resolvers are in resolv.conf because NM obviously uses system's
stub resolver.
If there are any valid integration pieces, please be
On 16.06.2015 00:30, Susi Lehtola wrote:
On 06/14/2015 03:02 PM, Sandro Mani wrote:
On 14.06.2015 16:28, Sandro Mani wrote:
Rules to generate such requires/provides:
* Provides: if the path of the library starts with $MPI_LIB, append
the (openmpi) resp (mpich) to the provides string
*
On Mon, Jun 15, 2015 at 3:02 PM, Miloslav Trmač m...@redhat.com wrote:
What would dnssec-trigger do if an attacker^Wlegitimate hotspot provider
deliberately let the hotspot probe lookup and connection through, but kept
redirecting everything else?
Detect it and show the sandboxed browser
Generally the problem is that resolv.conf is quite limited and cannot express
lot of things, like trust levels and per-domain forwarding (using different
servers for queries related to different domains).
One possibility how to solve this is to port applications to use different
library/API
Hello,
On Jun 13, 2015 4:28 AM, Michael Catanzaro mcatanz...@gnome.org wrote:
On Fri, 2015-06-12 at 15:49 -0700, Andrew Lutomirski wrote:
But that's not even right. Suppose you have a captive portal that
wants you to log in via your Google account. It can send you do
Apple (foolishly) used to use something like http://apple.com/hotspot
on their main site itself, which meant that using a VPN on demand could
never protect apple.com because the iphone had to leave that domain out
of the vpn trigger list or else all hotspot detection would be broken. It
seems
On Fri, Jun 12, 2015 at 7:24 AM, Neal Gompa ngomp...@gmail.com wrote:
What about some kind of virtual provides defined in repos/rpm/somewhere that
would automatically grab the kernel-devel package associated with the exact
kernel that is running at the time yum/dnf is installing a program
Hello,
= Proposed System Wide Change: Default Local DNS Resolver =
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
Install a local DNS resolver trusted for the DNSSEC validation running on
127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf.
We’ve
And generally I agree with the concern raised on the spins list
(https://lists.fedoraproject.org/pipermail/spins/2015-May/004222.html and
following) that the spin description can, at least by a quick read without
reading the actual kickstart, likely to be misunderstood to deliver more
than it
Yes, that's the way I understand it too. The distinction between local
and remote is that remote attacks are in general more likely and thus
dangerous.
This is a good assumption - I'm sure that on most installations of Fedora
there's just one or a few trusted users, and they outnumber
Hello,
Nevertheless, you raise an interesting question in general. The way
I understand the motivation for the restriction is to avoid any
chance of attack or unexpected access over the network. [...]
OK, so the question is - are we (still) trying to preclude -local-
Now, is it our task as the change owners to update each and every
package that depends on Mono?
We have done a lot of preparation work, but would welcome the package
owners to review our changes to the spec files and import them into
their packages...
Does it work like that?
Procedurally
On Mon, May 18, 2015 at 09:50:44AM -0600, Pete Travis wrote:
A spin is a big effort with many interoperating packages and coordination
with other teams (primarily releng, but you should also seek guidance from
QA). It qualifies as a System Wide Change.
Especially if this particular spin
While working for an updated ipcalc to support ipv6 transparently, I
figured we have more tools which are not IPv6-ready and awkwardly
provide an additional tool with a -6 suffix, supposedly for separate
IPv6 support. That looks like a relic of the past, we still drag. IPv6
support should be
Hello,
I confess I've only seen /usr/libexec used for add-on utilities, but
now I'm curious.
Does it make more sense for these sort of scripts to live in
/usr/libexec, or in /usr/share?
/usr/libexec. From (info standards):
`libexecdir'
The directory for installing executable
On Wed, Apr 22, 2015 at 8:06 AM, Miloslav Trmač m...@redhat.com wrote:
Hello,
I confess I've only seen /usr/libexec used for add-on utilities, but
now I'm curious.
Does it make more sense for these sort of scripts to live in
/usr/libexec, or in /usr/share?
/usr/libexec. From
I am writing patch for system-config-users that allows configure users ang
group from a IPA server with python library ipalib from package ipa-python.
I would like the changes be included in the system-config-users. What is the
best way to implement this from the point of view of architecture?
Hello,
Besides gnome-control-center then, I guess the switch of
systemd-timedated to only supporting systemd-timesyncd
impacts FreeIPA too.
Are you aware of
https://lists.fedoraproject.org/pipermail/devel/2014-November/204658.html ?
Mirek
--
devel mailing list
Hello,
Besides gnome-control-center then, I guess the switch of
systemd-timedated to only supporting systemd-timesyncd
impacts FreeIPA too.
Are you aware of
https://lists.fedoraproject.org/pipermail/devel/2014-November/204658.html ?
Yes, and I don't want to make changes to
Humans I can
understand having different views, but the tools should provide the humans
with
what we need here. In this case I think that means one of the following:
1) Require that the bot ignore bugs that are closed (assuming a majority
consensus agrees, which I understand isn't likely
===
#fedora-meeting: FESCO (2015-04-01)
===
Meeting started by mitr at 18:00:41 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2015-04-01/fesco.2015-04-01-18.00.log.html
.
Meeting summary
Following is the list of topics that will be discussed in the FESCo
meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/UTCHowto
or run:
date -d '2015-04-01 18:00 UTC'
Links to all tickets
Hello,
On Fri, Mar 27, 2015 at 08:28:21PM +0100, drago01 wrote:
Actually machine generated isn't per se bad ... it saves a lot of
effort and should be done more (for other packages too where
possible).
Why waste man power for something that can be automated?
As for tex ... we could
I wonder, are there any implications for dnf in terms of being consistent with
the new behavior of Gnome Software?
Wait, the metadata download and search code is not shared? What would it take
to make it so?
/me wonders how many unicorns and kittens will have to die before we get rid of
all
On Fri, 2015-03-06 at 12:00 -0700, Kevin Fenzi wrote:
* The workstation folks think this change could drive away some of
their potential users for not much gain. In their case, sshd is not
enabled/running and additional security for a device that sits in
your home isn't worth the
Hello,
On Fri, Mar 06, 2015 at 09:43:33AM -0500, Adam Jackson wrote:
As resolved by FESCO in our meeting on 4 March 2015, FESCO requests that
anaconda revert a password behaviour change in the UI from F22,
restoring the double-click to confirm weak password behaviour from F21
and earlier.
Note that in upstream bug #735578 I have failed to build consensus on
any form of password strength checking, let alone the strict checking
that is done by libpwquality, so there is little chance at this point of
GNOME upstream adhering to any policy you come up with. The status quo
is that
I have no
clue why VNC passwords are limited/truncated to eight characters, but it
seems like that limitation makes the protocol not worth supporting at
all, let alone worth promoting in System Settings.
The only VNC authentication mechanism standardized in RFC 6143 uses the
password as a
Hello,
On Fri, 2015-03-06 at 12:00 -0700, Kevin Fenzi wrote:
* The workstation folks think this change could drive away some of
their potential users for not much gain. In their case, sshd is not
enabled/running and additional security for a device that sits in
your home isn't worth
Adam Jackson wrote:
* #1412 anaconda password change is causing consternation among the user
community please review this policy decision (ajax, 18:24:10)
* AGREED: FESCo would like anaconda to turn back on the double-done
option for Fedora 22.
Thanks!
Better solutions
= Proposed System Wide Change: Legacy implementations of the Java platform in
Fedora =
https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora
== Detailed Description ==
This is no real work proposal.
Stepping back, I’m not sure this has been said explicitly: this is really a
packaging
On 02/24/2015 06:41 PM, Miloslav Trmač wrote:
Hello,
java would be the preferred JRE in Fedora. The package would have no
content, but it would have Requires on preferred Fedora JRE, currently
java-1.8.0-openjdk. This could be easily changed as default JRE changes.
The same is for other
Hello,
java would be the preferred JRE in Fedora. The package would have no
content, but it would have Requires on preferred Fedora JRE, currently
java-1.8.0-openjdk. This could be easily changed as default JRE changes.
The same is for other binary subpackages of java, respectively.
All
Communication is a two way street, and as an upstream I cannot be in
the business of pinging every single downstream about every single
change individually, in particular if I consider the change
unimportant.
Sure, that makes sense.
To learn about changes upstream, please follow the
On Thu, Feb 12, 2015 at 12:47:27PM +0100, drago01 wrote:
A better way would be to add a Fedora Signature in addition to
mozilla's and use that for packaged extensions.
But that would require work on the build system (koji) side.
The RPMs deploying the packaged extension are already
or simply exempt signature checking if
the extension is on disk. They should check on download only.
That would defeat the entire purpose; malware is very commonly sideloading
extensions.
Mirek
--
devel mailing list
devel@lists.fedoraproject.org
On Tue, Feb 10, 2015 at 11:08 AM, Miloslav Trmač m...@redhat.com wrote:
Following is the list of topics that will be discussed in the FESCo
meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net.
To convert UTC to your local time, take a look at
http://fedoraproject.org
Meeting started by mitr at 18:00:17 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2015-02-11/fesco.2015-02-11-18.00.log.html
.
Meeting summary
---
* init process (mitr, 18:00:23)
* Welcoming new FESCo members (mitr, 18:04:47)
* ACTION: mitr
Following is the list of topics that will be discussed in the FESCo
meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/UTCHowto
or run:
date -d '2015-02-11 18:00 UTC'
Links to all tickets
On 31 January 2015 at 21:57, Casey Jao casey@gmail.com wrote:
Are there any plans to let packages specify that they do not require a
total
system reboot to be updated?
Yes, see https://wiki.gnome.org/Projects/SandboxedApps -- basically,
you can't do updates of rpm-sourced
Hello,
in Fedora Rawhide there is a new major version of mongoDB 2.6. With this
new version names of mongoDB configuration files will be changed - to
reflect names used in upstream rpms
(http://downloads-distro.mongodb.org/repo/redhat/os/x86_64/RPMS/ )
mongodb.conf - mongod.conf
So, at today's FESCo meeting there was a good deal of discussion about
python as default:
http://meetbot.fedoraproject.org/fedora-meeting/2015-01-28/fesco.2015-01-28-18.02.log.html#l-41
in which we agreed defer this to F23, file bugs against rawhide after
branch (+6,0,0)
I really
(Speaking only for myself, not for all of FESCo; hoping others will chime in.)
- What if Anaconda does make it? :)
I don’t know.
- What is enough? It's possible that two or three packages may be still
unported even in F23 (and as for server livecd in F23, I think there will be
few more).
2-3
and the main point is: there is no need to replace network.service on
*any* static configured machine
(As a short-time initscripts comaintainer way-back-when:) There may not be a
need for anything smarter than init.d/network for machines with _trivial_
static configuration (a few interfaces
On 01/27/2015 07:03 AM, Bastien Nocera wrote:
All those are warnings, not garbage or debug output. File bugs about
those,
there should be zero warnings in normal usage.
Shouldn't they trigger abrt then?
Yes, that would be a great help towards making the warnings filed and fixed.
Care
On Fri, Jan 23, 2015 at 2:24 PM, Stephen Gallagher sgall...@redhat.com
My first question is why do there need to be four branded network
install releases? If they're all capable of making a workstation,
server, cloud image or generic Fedora, why not just have *one* network
install release and
There is in fact no strict *technical* requirement for anything to
move from yum to dnf in F22. yum will remain in the F22 package set,
it is not being removed.
However, the Change seems to me to have been written with the basic
idea that yum shouldn't be installed by default any more and
Hello,
== Scope ==
* Other developers: Unknown.
* Policies and guidelines: May need updates for RpmOstree.
This is too vague. What basis do have the other developers for commenting
about how they would be affected, knowing only the above?
== Detailed Description ==
The original
Hello,
** A build containing latest Django will be pushed to f22 branch late in dev
cycle. If we decide not to push Django-1.8, nothing will be broken.
** Django 1.8 final release is expected around April 1st, 2015: [2]
Note that the “Change checkpoint: completion deadline (testable)” is on
Hello,
Tunir is a self contained CI Continuous Integration [1] which will be used to
test Fedora Cloud images nightly.
What relationship, if any, does this have with Taskotron?
Do I understand correctly that this Change does not involve / require setting
up automated test runs by rel-eng or
On Wed, 2015-01-21 at 12:10 +0100, Vít Ondruch wrote:
I'd like to propose an amendment to allow
bringing packages even if no reviewers are available (the typical case).
Step 6: ... If the proposed package is not reviewed for 2 months, the
package must be reviewed by the submitter,
Please add this copr
https://copr.fedoraproject.org/coprs/whot/kcm_touchpad/
Please review this branch:
https://github.com/whot/kcm_touchpad/tree/wip/libinput-support
Thanks for taking on this additional work.
Mirek
--
devel mailing list
devel@lists.fedoraproject.org
On Thu, 2015-01-22 at 09:57 -0500, Miloslav Trmač wrote:
That's good for you, but unacceptable to me. That way we penalize people
who add packages.
Penalize in what sense?
In the sense, that in addition to packaging something new you have to
review something else in order to get your
== Scope ==
* Release engineering:
** Pre-loading roles will need to be a capability of the Anaconda install
system, both in the graphical installer and kickstart
While this functionality is desirable, it seems not to be directly related to
the database server.
Mirek
--
devel mailing
On Fri, 2015-01-16 at 15:39 +0100, Lubomir Rintel wrote:
There's a chance of a successful exploitation that would result in
obtaining my privileges. Sure, gaining access to my account is bad
enough, but if I run su or sudo, they have root!
Along these lines, someone pointed out a
On Tue, Jan 13, 2015, at 04:41 PM, Colin Walters wrote:
If it's installing a regular file, then it won't work - the package
(daemon) needs to create it on start.
I filed a bug about this:
https://bugzilla.redhat.com/show_bug.cgi?id=1182785
Though I wonder if this should be a Change
On Wed, Jan 14, 2015 at 02:24:29PM +, Peter Robinson wrote:
I was thinking exactly that, mass rebuild is scheduled for Jan 30th
according to the schedule [1] with branching 10 days or so later. That
is only two weeks away. With statements like The release will happen
probably in the
* Contingency mechanism: Revert to older gcc, mass rebuild everything again
* Contingency deadline: Before release
This is an invasive contingency mechanism, requiring retesting a lot of
functionality; the contingency deadline for this (i.e. when we need to be
comfortable that the revert will
On Wed, 14 Jan 2015 12:34:22 -0500 (EST)
Miloslav Trmač m...@redhat.com wrote:
On Wed, 14 Jan 2015 16:54:09 + (UTC)
P J P pj.pan...@yahoo.co.in wrote:
I'd request all(those who are opposing) too describe their
requirements in the etherpad page above.
Being able
On Wed, 14 Jan 2015 16:54:09 + (UTC)
P J P pj.pan...@yahoo.co.in wrote:
On Wednesday, 14 January 2015 8:01 PM, Simo Sorce wrote:
Ok, I state my opposition to without-password too inequivocably
here. Mostly because it is just the same as 'no', given there is no
way, in a regular
On Tue 13 Jan 2015 01:35:26 AM CET Kevin Kofler wrote:
I actually think that cmake should be added to the minimal build root,
instead of removing stuff. Almost all the packages I work on BuildRequire
cmake (which also implies that they need make to build, and gcc-c++ is the
typical
== Scope ==
* Other developers:
*** Use systemd-tmpfiles instead of placing content in /var (TODO: better
docs
for this)
Is this a strict dependency or a nice-to-have item? That is, are we talking
about having to change all such packages in Fedora (or some specific subset)
within the
Jaroslav, there is a lot more information on the actual wiki page.
Like the fact that this is only for particular opt-in new installs and
that yum/dnf/RPM can only operate in read-only mode on such installs.
Could you resend this with the entirety of the text? It might lead to
fewer
Dne 13.1.2015 v 08:12 Ralf Corsepius napsal(a):
On 01/13/2015 07:12 AM, Stanislav Ochotnicky wrote:
On Tue 13 Jan 2015 01:35:26 AM CET Kevin Kofler wrote:
Vít Ondruch wrote:
I basically see several issues:
1. The sheer amount of packages being affect.
snip data
By all accounts we are
Scrap that, Kevin Kofler pointed me to this post:
https://lists.fedoraproject.org/pipermail/devel/2014-December/205490.html
Which I unfortunately missed, so the info I got from KDE upstream is
not correct because the KDE spin adds an extra component which does
directly talk to the low
- Original Message -
Does this proposal apply to native non-C/C++ programs?
As written, it seems to intend so. In practice, it would probably apply or not
depending on whether the non-C/C++ programs’ builds are affected by
_hardened_build.
Ideally, I think this should apply to all
That said, even on x86_64 it isn't anything close to no overhead.
Tried last night to rebuild GCC's cc1plus as -fpie -pie, and then
rebuild stage3 of GCC with make -j1 separately with the original stage3
cc1plus (ET_EXEC binary) and PIE cc1plus (ET_DYN). The build (which
included still time
- The 'method' used to restrict remote root access is negotiable. Ie. disable
it completely by setting PermitRootLogin=no OR disable remote root login
via password by setting PermitRootLogin=without-password.
(The general theme of this mail: Being flexible is fine, and establishing this
- improves accountability for administrative actions (we know which admin
messed up :)
Nonsense. for non-malicious logins, sudo leaves as much as a trail as
sshd which tells you which credentials were used to login. For malicious
logins, once root access is obtained via password-less
Dne 7.1.2015 v 21:14 Stephen Gallagher napsal(a):
* #1379 F22 System Wide Change: Change xorg input stack to use libinput
- https://fedoraproject.org/wiki/Changes/LibinputForXorg (sgallagh,
19:51:28)
* AGREED: Approved with two caveats: 1) Both GNOME and KDE must be
Hello,
= Proposed System Wide Change: Harden all packages with position-independent
code =
Harden all packages with position-independent code to limit the damage from
certain security vulnerabilities.
So this proposal is for _all_ architectures, including the register-starved
32-bit i?86
The only other approach I could see for the headless
servers would be mandating the enrollment in an identity domain at
installation time (such as to FreeIPA or Active Directory).
And in this scenario we should absolutely disable PermitRootLogin.
So that if you have issues with
- Original Message -
= Proposed System Wide Change: Set sshd(8) PermitRootLogin=no =
https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no
In the Server case, nearly every deployment is headless. Disabling root
login to ssh by default would mean that many people would have
On Tue, Jan 6, 2015 at 10:20 AM, Nikos Mavrogiannopoulos n...@redhat.com
wrote:
I've created a transition tracker to system-wide crypto policy at:
https://bugzilla.redhat.com/show_bug.cgi?id=1179209
snip
Also, what about situations where SSL/TLS is off by default in the
While I think you are right in some cases like cashier, isn't this
discussion really about the Fedora Workstation?! Since for this the
target user is a developer, can we just agree that in this case the user
needs both CLI and GUI apps (although some developers certainly sticks
to one of
(on CLI)
and developers deserve a better environment.
No, developers deserve the environment they ask for, not what someone
else thinks is better.
There are aspects of the shell that are a matter of pure preference, like
syntax coloring.
There are aspects where personal preference or
Hello,
Am 02.01.2015 um 21:05 schrieb Miloslav Trmač:
Here, GUIs _as a category_ (not necessarily the GUIs we are currently
providing) should always be better than CLIs _as a category_ simply
because the GUI can in the worst case just copy the CLI layout and
behavior so
- Original Message -
well, and that is why there are tasks you *can * do 1000 times more
better in a terminal or in a 3-liner shell script with one or two params
and others where you are much faster using the GUI
this world is grey
hence everybody start using Linux should *know*
- Original Message -
If we want to have this working correctly with chronyd/ntpd, at this point
it seems the only reasonable option is to replace systemd-timedated.
timedatex is a new implementation of the timedate interface that was
recently added to Fedora. It reads the list of NTP
Hello,
- Original Message -
On Mon, 03.11.14 09:13, Miloslav Trmač (m...@redhat.com) wrote:
Hello,
- Original Message -
On Fri, 31.10.14 10:04, Andrew Lutomirski (l...@mit.edu) wrote:
I filed an FPC ticket: https://fedorahosted.org/fpc/ticket/467
Thoughts
- Original Message -
On Fri, Oct 31, 2014 at 01:59:30PM -0400, Miloslav Trmač wrote:
- Original Message -
I filed an FPC ticket: https://fedorahosted.org/fpc/ticket/467
Thoughts?
My intuition is that if an application needs _everything_ in /usr to
be readable
Hello,
- Original Message -
On Fri, 31.10.14 10:04, Andrew Lutomirski (l...@mit.edu) wrote:
I filed an FPC ticket: https://fedorahosted.org/fpc/ticket/467
Thoughts?
I very much agree with this, but I'd really prefer if we'd list what
is allowed rather than just declare what
- Original Message -
I can't speak for virtme, but supermin won't read new files that are
added by the administrator. It only looks at files that it knows
(from RPM metadata) are part of RPM-installed packages, and only a
fixed list of Fedora-packaged RPMs are consulted, not random
- Original Message -
I filed an FPC ticket: https://fedorahosted.org/fpc/ticket/467
Thoughts?
My intuition is that if an application needs _everything_ in /usr to be
readable then it is likely broken. Something being placed in /usr does _not_
imply that it is supposed to be used by
- Original Message -
I created a new bug [1] that explains that ssmtp is sending all cron
jobs output to an external SMTP server. I marked it as a security bug,
the security tag was removed and it was recommend to make it public,
something I can't do. I will resume the problem here,
- Original Message -
On Thu, Oct 9, 2014, at 11:09 AM, Miloslav Trmač wrote:
especially as we are taking the RPM-level control away from the users
completely in cloud
How is that?
We ship filesystem images with many installed packages. Removing the packages
from an existing
(reordering the citations!)
Why should we ban weak dependencies if they really
do nothing in YUM?
We need a precise and detailed functional description about what these
weak dependencies are supposed to do.
Do you mean something like this?
- Original Message -
Most importantly, we need to update packaging guidelines to explain
what are the semantic differences between these different tags. But
that's a minor update.
That seems to be well enough covered upstream. (Well modulo “does Fedora
actually do what the upstream
- Original Message -
The Fedora question would be not “what do the tags do” but “when is it
appropriate to use Suggests, when Recommends, and when Requires”?
(And FWIW my take is that having this level of complexity in the dependency
system is a mistake that is making things complex
- Original Message -
On 6 October 2014 17:28, Miloslav Trmač m...@redhat.com wrote:
- Original Message -
usage/requirement as well. Bringing the benefits of supporting dash to…
the satisfaction of pedantically using the POSIX /bin/sh path as
frequently as possible
- Original Message -
On Fri, Oct 03, 2014 at 02:29:53PM -0600, Orion Poplawski wrote:
Is it worth considering using Dash as the default (non-interactive)
shell in Fedora? Other distributions including Ubuntu and Debian
(https://lwn.net/Articles/343924/) have been using dash as the
- Original Message -
At that point switching anything to dash can _only increase_, not reduce,
the disk space needed, and is very likely to increase the total page cache
usage/requirement as well. Bringing the benefits of supporting dash to…
the satisfaction of pedantically using
Hello,
On Thu, Oct 2, 2014 at 10:48 AM, Tom Rivers wrote:
On 10/2/2014 09:58, Rahul Sundaram wrote:
I didn't address it because it was not really relevant either. The
impetus
is
merely the backstory.
On the contrary, the rationale for your proposed change is very
The expected security improvement is essentially nonexistent. In the current
case of importing functions from the environment (and we could have a looong
philosophical conversation about whether this is a vulnerability in bash or
in its callers, where the likely outcome is “not a vulnerability
Hello,
(resurrecting an really old thread, sorry about the delay.)
- Original Message -
1) Will I (as a hobbyist packager) be able to reach the proper
conclusion, e.g. find the real place where these defaults are set, such
as [4, 5]?
If you, as the package maintainer, who knows the
- Original Message -
IMHO, we need a crypto-expert or team to formally review this proposal,
Nikos, who proposed this, is a crypto expert :)
to identify packages it affects and to advise packagers and upstreams on
how to implement this, because I feel this proposal is way beyond the
Hello,
- Original Message -
At the moment applications have to provide an icon = 32x32px in size
to be included in the AppStream metadata and shown in the software
center. This is *tiny* on a HiDPI screen, so should I mandate that all
applications ship a 64x64 (and ideally,
1 - 100 of 746 matches
Mail list logo
