Preventing supply chain attacks via rekor
Hi All, I am sure everyone has heard about the recent Solarwinds software supply chain attacks. This attack has made all software vendors think about securing their supply chain, and it is even more applicable to linux distributions which are made of thousands of components built from sources they dont even have control over. One possible step in this direction is the ability to ensure that there is no distribution point tampering of binaries shipped in Fedora. rekor is a an immutable tamper resistant ledger of metadata generated within a software projects supply chain. Rekor will enable software maintainers and build systems to record signed metadata to an immutable record. How would it work, would package maintainers need to be involved? Not really, this could be a post-build thing, in which ones the rpms reach stable and are signed, rekor would run on it and store the binary metadata in the transparency logs. I just wanted to send out a email to fedora folks to get a feel of this and what you think, before really going into implementation or any other details. More information at: https://sigstore.dev/what_is_sigstore/ https://github.com/sigstore/rekor -- Regards, Huzaifa Sidhpurwala / Red Hat Product Security ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)
I can do it, once its gets approved/included On Thu, Jun 10, 2021 at 6:21 PM Neal Gompa wrote: > On Mon, Jun 7, 2021 at 3:00 PM Ben Cotton wrote: > > > > > https://fedoraproject.org/wiki/Changes/yescrypt_as_default_hashing_method_for_shadow > > > > == Summary == > > Make the yescrypt hashing method the default method used for new user > > passwords stored in /etc/shadow. > > > > > > == Owner == > > * Name: [[User:besser82| Björn Esser]] > > * Email: besse...@fedoraproject.org > > > > > > == Detailed Description == > > yescrypt is a password-based key derivation function (KDF) and > > password hashing scheme. It builds upon Colin Percival's scrypt, and > > is based on NIST-approved primitives. > > > > Cryptographic security of yescrypt (collision resistance, preimage and > > second preimage resistance) is based on that > > of SHA-256, HMAC, and PBKDF2. Even a catastrophic failure of > > yescrypt’s computational layers to maintain entropy would not affect > > yescrypt’s cryptographic properties as long as SHA-256, HMAC, and > > PBKDF2 remain unbroken. That said, in case SHA-256 is ever broken, > > yescrypt’s additional processing is likely to neutralize the effect of > > any such break. > > > > By the time of this writing, sha256crypt and sha512crypt, as used > > commonly today for hashing passwords, remain unbroken, but have some > > flaws by design: > > > > * Both hashing methods effectively only use about 90 bits of salt, > > although the NIST-recommendation for salt length is >= 128 bits. > > * Long passwords can create a denial-of-service on the CPU. > > * Passive observation of execution times can predict password length. > > * No use of a crytographic key derivation function (KDF). > > > > In conclusion we should move to a stronger hashing method for > > computing the entries in the UNIX shadow file. So why not Argon2? > > > > * yescrypt has a dependency not only on RAM, but also on fast on-die > > local memory, which provides bcrypt-like anti-GPU properties even at > > very low per-hash RAM sizes (where Argon2 might even lose to bcrypt in > > terms of GPU attack speed). > > * yescrypt currently has less low-level parallelism within processing > > of a block, yet allows for tuning it later, whereas Argon2 has a fixed > > and currently commonly excessive amount of such parallelism, which may > > be extracted to speed up e.g. GPU attacks through use of more > > computing resources per the same total memory size due to each hash > > computation's memory needs being split between 32 threads (yescrypt > > currently has four 16-byte lanes that can be processed in parallel > > within a 64-byte sub-block before running into a likely data > > dependency for the next sub-block, whereas Argon2 allows for parallel > > processing of eight 128-byte chunks within a 1 KiB block with only two > > synchronization points for the entire block, as well as of four > > 32-byte parts of the 128-byte chunks with only two more > > synchronization points for the entire 1 KiB block). > > * yescrypt's cryptographic security is provided by SHA-256, HMAC, and > > PBKDF2, which are NIST-approved and time-tested (the rest of > > yescrypt's processing, while most crucial for its offline attack > > resistance properties, provably does not affect its basic > > cryptographic hash properties), whereas Argon2 relies on the newer > > BLAKE2 (either choice is just fine for security, but use of approved > > algorithms may sometimes be required for compliance) > > > > Also see [https://www.openwall.com/yescrypt/ yescrypt - scalable KDF > > and password hashing scheme], the > > [https://www.password-hashing.net/submissions/specs/yescrypt-v2.pdf > > PHC submission paper], > > [https://lists.openwall.net/phc-discussions/2018/03/13/10 PHC yescrypt > > vs. Argon2], and > > [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978553 the > > discussion on the Debian bugtracker]. > > > > > > == Feedback == > > No feedback, yet. > > > > > > == Benefit to Fedora == > > yescrypt is the default password hashing scheme on recent ALT Linux, > > Debian testing, and Kali Linux 2021.1+, so we should adopt it as the > > default, too. Also, it is already the recommended hashing method in > > the [ > https://docs.fedoraproject.org/en-US/fedora-coreos/authentication/#_using_password_authentication > > Fedora CoreOS documentation]. > > > > > > == Scope == > > * Proposal owners: Help with integration for yescrypt support in some > > packages. See Dependencies. > > * Other developers: Integrate yescrypt support in some packages. See > > Dependencies. > > * Release engineering: [https://pagure.io/releng/issue/10150 #10150] > > * Policies and guidelines: N/A (not needed for this Change) > > * Trademark approval: N/A (not needed for this Change) > > * Alignment with Objectives: N/A (not needed for this Change) > > > > > > == Upgrade/compatibility impact == > > No impact, as password hashes, that have been computed using the > > former default sha512crypt, will
Re: Fedora Security Team
I dont think creating 5 bugs per CVE is a correct statement here. We create one bug per product per CVE. So if fedora is affected with a node.js, we create one fedora tracker per CVE. The tracker should block the CVE bug, so it should be easy to find. Also you can search for bugs with SecurityTracking whiteboard if you cant find otherwise. Let me know if you need help, in tracking your fedora security bugs :) - Original Message - From: "Stephen Gallagher" To: "Development discussions related to Fedora" Sent: Wednesday, November 4, 2020 8:31:32 PM Subject: Re: Fedora Security Team On Tue, Nov 3, 2020 at 11:39 AM Marek Marczykowski-Górecki < marma...@invisiblethingslab.com > wrote: On Tue, Nov 03, 2020 at 10:02:24AM +, P J P wrote: > * Right, Fedora package CVEs and relevant bugs are filed by Red Hat Product > security team. > > * CVEs/bugs are fixed in the upstream sources first. Fedora package > maintainers do rebuild > of the package with released fixes. I see currently over 1000 such tracking bugs[1]. I realize it some cases it may be missing upstream fix and it is not a Fedora package maintainers responsibility to develop a fix (although anyone can help upstream to develop a fix). But by looking at few random items there, it seems the fix is available in a subsequent upstream release and what is missing is just bumping the package version in Fedora. In some (many?) cases, the newer package is even already there, but the missing part is closing related tracking bug (and I'd guess the update lacked info it was a security fix, but I haven't verified that). I'm definitely guilty of the latter part, particularly for Node.js. Generally, whenever Node.js issues a security release, they do so for multiple issues simultaneously. When Product Security then goes and creates Bugzilla tickets, they create many (sometimes up to five bugs per CVE). It becomes nearly impossible to keep up with the bug maintenance in such situations. The process is just too heavyweight and I often end up just doing the upstream releases and ignoring the BZs. If we want this to be more accurate, we really need to have a more streamlined and/or automated solution for these issues. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RFC: Security policy adjustments to make it easier to implement and more friendly to maintainers
On 1/30/20 4:11 PM, Vít Ondruch wrote: > > Dne 30. 01. 20 v 11:09 Zbigniew Jędrzejewski-Szmek napsal(a): >> On Thu, Jan 30, 2020 at 10:05:28AM +0100, Vít Ondruch wrote: >>> Thank you for looking into this matter. >>> >>> >>> Dne 29. 01. 20 v 22:26 Miro Hrončok napsal(a): >>>> Hello, Fedora has an approved security policy since September 2018 [0]: >>>> >>>>> If a CRITICAL or IMPORTANT security issue is currently open >>>>> against a package, or a security issue of lower severity has been >>>>> open for at least 6 months, four weeks before the branch point a >>>>> procedure similar to long-standing FTBFS will be triggered >>>>> immediately, with 8 weeks of weekly notifications to maintainers and >>>>> subsequent orphaning and then subsequent removal from distribution. >>>>> This applies to all packages, not just leaf. >>>> I have decided to have a look into this, since this has been approved >>>> more than a year ago and nothing ever happened since. Fedora has a >>>> very big pile of open CVE bugzillas [2]. >>> >>> I just wonder what is the actual state of these bugs? Which Fedora >>> versions they apply? >>> >>> The problem with these trackers is that they are filed against "fedora" >>> i.e. against all maintained version. If if fix this bug in Rawhide, >>> should the bug be kept open? Probably. But in what state? The "fixed in" >>> field would be probably updated by me, but AFAIK, nobody mandates Fedora >>> maintainers to populate this field. >> It is automatically set when an update that is marked to fix the bug >> goes through bodhi. > > > This does not apply for Rawhide, does it? And if it does, then it does > not apply when you fix the bug just via regular rebase, when not > mentioning any specific BZ in changelog. > Here is what Product Security does: 1. If multiple released fedora versions are affected, we file one bug against "fedora-all" 2. If some version if affected and others are not, we file product specific bug We dont look at rawhide currently. So these open bugs are only against releases. > > Vít > > >> >> Zbyszek >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Huzaifa Sidhpurwala / Red Hat Product Security ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RFC: Security policy adjustments to make it easier to implement and more friendly to maintainers
On 1/30/20 3:19 AM, Richard W.M. Jones wrote: > On Wed, Jan 29, 2020 at 10:26:56PM +0100, Miro Hrončok wrote: >> Here is an initial (albeit randomly generated) proposal of X and Y: >> >> severity CRITICAL/HIGH MEDIUM LOW >> X 2 4 6 >> Y 2 4 6 > > In RHEL, low impact security bugs wouldn't normally be fixed until the > next minor release, which would be 6-12 months after the issue is > reported. I don't think it's valuable to badger packagers about bugs > that have "minimal consequences" to use the terminology from > > https://access.redhat.com/security/updates/classification There are various reasons why lows are not fixed immediately in RHEL, including the fact that customers dont like too many updates because of production systems downtime. Not all of them may be applicable for fedora users. The above being said, i am ok with deferring lows, but please lets fix or close others? > > Rich. > -- Huzaifa Sidhpurwala / Red Hat Product Security ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RFC: Security policy adjustments to make it easier to implement and more friendly to maintainers
On 1/30/20 8:32 AM, Kevin Kofler wrote: > Miro Hrončok wrote: >> My idea was that within half a year, it should be wither fixed or CLOSED >> as WONTFIX or UPSTREAM. If we don't agree, I'm completely fine making it >> 12 months or even ignore such bugs in the policy entirely. > > I don't see how it is an improvement to close security fixes that are > blocking on upstream (in)action as UPSTREAM, as opposed to keeping them open > so that it is clear to everyone that they need to be fixed. > Issues which are blocking on upstream, will eventually get resolved once upstream figures out a solution in some time, maybe with subsequent rebases. > I think that the policy being discussed here just ought to be dropped > entirely, because it will do absolutely nothing to make Fedora actually more > secure, but only amounts to extra bureaucracy and extra work for packagers. If fixing security issues is extra work for packagers, then we are doing something wrong here. What percentage of security flaws will be closed:upstream? Why do we drop other fixes for such issues and eventually end up having tons of pending fixes. Do we want to continue the same condition as described here: https://mivehind.net/2020/01/28/Fedora-has-too-many-security-bugs/ > > Kevin Kofler > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Huzaifa Sidhpurwala / Red Hat Product Security ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G
On 3/15/19 9:49 PM, Richard W.M. Jones wrote: > On Fri, Mar 15, 2019 at 04:15:58PM +, Richard W.M. Jones wrote: >> On Mon, Mar 11, 2019 at 01:56:14PM -0400, Ben Cotton wrote: >>> https://fedoraproject.org/wiki/Changes/HardenedCompiler >> >> I'm not opposing this, but is it possible we could do this without >> breaking clang at the same time? >> >> In the past (and currently) the Fedora compiler flags need some hairy >> editing so they work with clang, eg: >> >> https://src.fedoraproject.org/rpms/american-fuzzy-lop/blob/master/f/american-fuzzy-lop.spec#_110 >> >> (Actually this is not the latest iteration - latest clang 7 and gcc 9 >> and Fedora 30+ needs even more editing, but I didn't push it yet since >> there are other issues with this package.) >> >> It would be nice if there was a way we could avoid this. > > So after rereading the proposal more carefully it seems as if the > proposal is to change the defaults in GCC so no flags would need to be > specified. Would we consequently remove those flags from the command > line (which would solve my problem above)? The flags in my proposal will be removed from the command line during the Fedora build process, since they are now default. Only people who dont want to use these flags due to some reason will need to unset them (I am assuming there are not a lot of packages like that) Currently based on Jakub's suggestion i am also planning to remove to fortify_source flag and keep others. The plan is to start some where and each release work with glibc and other teams so that we make more such security flags as default and also work with packages which break due to inclusion of such flags. -- Huzaifa Sidhpurwala / Red Hat Product Security Team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G
On 3/13/19 5:22 PM, Jakub Jelinek wrote: > On Wed, Mar 13, 2019 at 12:38:02PM +0100, Dridi Boukelmoune wrote: >> On Wed, Mar 13, 2019 at 12:19 PM Jakub Jelinek wrote: >>> >>> On Mon, Mar 11, 2019 at 01:56:14PM -0400, Ben Cotton wrote: >>>> https://fedoraproject.org/wiki/Changes/HardenedCompiler >>>> >>>> == Summary == >>>> By Default enable a few security hardening flags which are used with GCC. >>> >>> I'm strongly against this, the reasons have been explained multiple times. >>> >>> We have annobin and easy way to determine what misses to propagate the flags >>> down. >> >> I think the key sentence here is this one: >> >>> == Benefit to Fedora == >>> We provide better security both for our packages and for >>> applications/programs which users are building. >> >> IMHO this should have nothing to do with our packages since we already >> have guidelines regarding hardening and in most cases it should be the >> case without package maintainer intervention (exotic build systems or >> misuse or misconfiguration do exist). >> >> To me this change should only be meant for end-users of GCC, not the >> Fedora build infrastructure itself. > > I'm all for making it easier for users, say by adding > hardened-gcc/hardened-g++ wrappers or some dir with gcc/g++ wrappers users > can prepend in PATH if they want certain behavior, but changing the defaults > of what gcc does is a huge mistake. I know some distros have done it for > certain options, that doesn't change my opinion about it. > The thing is, when the defaults change, then people using the compiler need > to start using -fno-pie, -U__FORTIFY_SOURCE, -fno-stack-protector and the > like whenever they do want normal behavior, and as cross environments you > can't rely on the same defaults you need to stick those or the hardening > flags everywhere because you don't know what the compiler of the day will > do. Not to mention that -D__FORTIFY_SOURCE=2 rejects some valid C programs, > so gcc would be no longer standard compliant (and e.g. glibc headers warn > about it when used with -O0). > It is a similar reason why gcc doesn't change all of sudden -O0 default to > -O2. If -D__FORTIFY_SOURCE=2 breaks applications we can exclude that from the default flags. However i still think we should keep the other flags. Its upto developers to disable security flags if they want to, but that does not mean we should have default secure options. We assume that developers know what they are doing when they disable these flags. Also if it breaks on some arches, we can probably only enable it on x86_64 to start with. > > Jakub > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Huzaifa Sidhpurwala / Red Hat Product Security Team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G
On 3/13/19 5:30 PM, Daniel P. Berrangé wrote: > On Mon, Mar 11, 2019 at 01:56:14PM -0400, Ben Cotton wrote: >> https://fedoraproject.org/wiki/Changes/HardenedCompiler >> >> == Summary == >> By Default enable a few security hardening flags which are used with GCC. >> >> == Owner == >> * Name: [[User:huzaifas|Huzaifa Sidhpurwala]] >> * Email: huzai...@redhat.com >> * Release notes owner: huzai...@redhat.com >> >> >> == Detailed Description == >> Currently GCC does not enable any security hardening flags by default. >> They have to be explicitly enabled by the developers one-by-one. >> Ubuntu (https://wiki.ubuntu.com/ToolChain/CompilerFlags) however >> enables them and therefore has a hardened compiler by default. Each of >> these options can be explicitly disabled if required by the developer >> via a GCC command line flag. I am currently proposing the following >> flags be enabled by default. >> >> '''-Wformat -Wformat-security -fstack-protector-strong >> --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -O' > >> | 1 || -Wformat || Check calls to "printf" and "scanf", etc., to make >> sure that the arguments supplied have types appropriate to the format >> string specified, and that the conversions specified in the format >> string make sense. || -Wno-format >> |- >> | 2 || -Wformat-security || If -Wformat is specified, also warn about >> uses of format functions that represent possible security problems. >> || -Wno-format should disable this as well > > These two are very valuable warnings. If a C application's existing > build process has not already enabled them by default, I would expect > they'll trigger a great number of warnings. > > We're not using -Werror in Fedora though, so these will not cause a > build failure. > > Are we expecting Fedora maintainers to read the build logs & look for > these new warnings & report them upstream for fixing ? I'm sceptical > that many maintainers are going to put effort into that kind of thing > if it isn't blocking their builds. > Its upto the package maintainer to use -Werror to block builds which show these warnings. I dont think we should enforce at this point. But maybe at some time later we could: 1. Do an automated scan of build logs to figure out which packages show these warnings and figure out how to handle them. 2. For critical packages like network daemons etc, we could actively block packages which show these warnings. Overall as i mentioned before, i would like to start somewhere :) -- Huzaifa Sidhpurwala / Red Hat Product Security Team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G
On 3/13/19 5:55 PM, Daniel P. Berrangé wrote: > On Wed, Mar 13, 2019 at 12:21:29PM +, Tom Hughes wrote: >> On 13/03/2019 12:00, Daniel P. Berrangé wrote: >>> On Mon, Mar 11, 2019 at 01:56:14PM -0400, Ben Cotton wrote: >>> >>>> | 1 || -Wformat || Check calls to "printf" and "scanf", etc., to make >>>> sure that the arguments supplied have types appropriate to the format >>>> string specified, and that the conversions specified in the format >>>> string make sense. || -Wno-format >>>> |- >>>> | 2 || -Wformat-security || If -Wformat is specified, also warn about >>>> uses of format functions that represent possible security problems. >>>> || -Wno-format should disable this as well >>> >>> These two are very valuable warnings. If a C application's existing >>> build process has not already enabled them by default, I would expect >>> they'll trigger a great number of warnings. >>> >>> We're not using -Werror in Fedora though, so these will not cause a >>> build failure. >> >> Actually the default optflags already has -Wall (which includes >> -Wformat) and -Werror=format-security which enables that warning >> and turns on -Werror for it. > > I wonder why this change is suggesting to add the flags if they > are already present in our current optflags ? > These gets enabled when you build packages via koji, not when you use gcc to build packages. Having them enabled by default in gcc, ensures that user applications get them by default. -- Huzaifa Sidhpurwala / Red Hat Product Security Team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G
Hi Vit,
On 3/12/19 5:40 PM, Vít Ondruch wrote:
> Will it help to mitigate issues such as:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1284684
>
This is related to the following change which was made in Fedora 23:
https://fedoraproject.org/wiki/Changes/Harden_All_Packages.
My proposal does not touch PIE or RELRO at all, but is related to
compiling code with protections which mitigate, format string attacks
and stack-based buffer overflows. It is pretty common to enable these
flags while compiling, its just strange that we dont enable these by
default.
> and mitigate workarounds such as:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1543394
>
> That would be wonderful.
>
>
> Also, while OT to this specific change, I would love to have ability to
> have some compiler flags tailored to my environment. E.g. enabled
> optimizations specific to my CPU. That could enable potential of JIT
> compilation in Ruby and possibly everywhere else where compiler is
> involved in installation some extensions from 3rd party repositories.
>
>
> Vít
>
>
> Dne 11. 03. 19 v 18:56 Ben Cotton napsal(a):
>> https://fedoraproject.org/wiki/Changes/HardenedCompiler
>>
>> == Summary ==
>> By Default enable a few security hardening flags which are used with GCC.
>>
>> == Owner ==
>> * Name: [[User:huzaifas|Huzaifa Sidhpurwala]]
>> * Email: huzai...@redhat.com
>> * Release notes owner: huzai...@redhat.com
>>
>>
>> == Detailed Description ==
>> Currently GCC does not enable any security hardening flags by default.
>> They have to be explicitly enabled by the developers one-by-one.
>> Ubuntu (https://wiki.ubuntu.com/ToolChain/CompilerFlags) however
>> enables them and therefore has a hardened compiler by default. Each of
>> these options can be explicitly disabled if required by the developer
>> via a GCC command line flag. I am currently proposing the following
>> flags be enabled by default.
>>
>> '''-Wformat -Wformat-security -fstack-protector-strong
>> --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -O'
>>
>> {| class="wikitable"
>> |-
>> ! No !! Flag !! Use !! How to disable
>> |-
>> | 1 || -Wformat || Check calls to "printf" and "scanf", etc., to make
>> sure that the arguments supplied have types appropriate to the format
>> string specified, and that the conversions specified in the format
>> string make sense. || -Wno-format
>> |-
>> | 2 || -Wformat-security || If -Wformat is specified, also warn about
>> uses of format functions that represent possible security problems.
>> || -Wno-format should disable this as well
>> |-
>> | 3 || -fstack-protector-strong || Like -fstack-protector but includes
>> additional functions to be protected --- those that have local array
>> definitions, or have references to local frame addresses.
>> || -fno-stack-protector
>> |}
>>
>>
>> == Benefit to Fedora ==
>> We provide better security both for our packages and for
>> applications/programs which users are building.
>>
>> == Scope ==
>> * Proposal owners: Patch gcc to enable these options by default. Patch
>> should be very simple, since the compile/link code isnt actually
>> touched.
>> * Other developers: Developers need to ensure that Fedora package is
>> built and if any build failures they are corrected
>> * Release engineering: [https://pagure.io/releng/issue/8204 #8204]
>> * Policies and guidelines: The policies and guidelines do not need to
>> be updated.
>> * Trademark approval: Not needed for this change
>>
>> == Upgrade/compatibility impact ==
>> None
>>
>> == How To Test ==
>> Run "gcc -Q -v " to check if these flags are enabled by default
>>
>> == User Experience ==
>> Fedora is more secure because the entire distribution is compiled with
>> the correct security technologies enabled. Developers dont have to
>> worry about enabling the right flags when they compile their
>> application in Fedora because the compiler has them enabled by
>> default.
>>
>> == Dependencies ==
>> All packages will be rebuild with new GCC options.
>>
>> == Contingency Plan ==
>> * Contingency mechanism: Roll back the GCC options and use the default ones.
>> * Contingency deadline: Beta Feeze
>> * Blocks release? No
>>
>>
>>
>>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of C
Re: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G
On 3/11/19 11:48 PM, Florian Weimer wrote: > * Ben Cotton: > >> '''-Wformat -Wformat-security -fstack-protector-strong >> --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -O' > > --param=ssp-buffer-size=4 will not affect anything because > -fstack-protector-strong uses a completely different heuristic. > >> == Benefit to Fedora == >> We provide better security both for our packages and for >> applications/programs which users are building. > > We can check using annocheck if there are packages missing hardening and > fix them. What's the current level of coverage we have? > The intention is to have a secure compiler defaults. I have not taken a survey of what is the current coverage, but that is not really the goal here. Also having secure defaults help with user applications and not only fedora packages. > Have the Red Hat Enterprise Linux 8 packaging changes been upstreamed? > We were aiming for nearly-complete coverage there. > Not sure about this, but again this is not the aim. >> == Scope == >> * Proposal owners: Patch gcc to enable these options by default. Patch >> should be very simple, since the compile/link code isnt actually >> touched. > > -D_FORTIFY_SOURCE=2 by default needs patching of glibc because of the > pesky warning it prints without optimization. What is the amount of work this requires? Can we aim this for F31? Also these are warnings and not errors i assume? > > What about PIE by defauld and non-lazy binding by default? These two > are probably the two hardest to get right with CFLAGS/LDFLAGS injection. > (PIE is the reason for the -specs= hack.) > I am aiming this for F32, The intention is to add small number of secure defaults to GCC for each release. I am open to add PIE by default though, if you feel its not going to break large number of packages. > PIE-by-default compilers are very common already, although there are > many StackOverflow questions from peopel who use them and follow older > training material. > > Thanks, > Florian > -- Huzaifa Sidhpurwala / Red Hat Product Security Team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Expect nag email if you are maintaining a package in fedora with important/critical flaw open against it
On 2/21/19 12:55 PM, J. Scheurich wrote: > >> Really nothing else to say here, apart from $SUBJECT. >> >> Expect nag email if you are maintaining a package in fedora with >> important/critical flaw open against it > | ... Red Hat Product Security Team > > Is this security related or can i nag about the FE-NEEDSPONSOR flag in > wdune ? > This is related to https://pagure.io/fesco/issue/2090#comment-554987 -- Huzaifa Sidhpurwala / Red Hat Product Security Team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Expect nag email if you are maintaining a package in fedora with important/critical flaw open against it
Hello, Really nothing else to say here, apart from $SUBJECT. Thanks! -- Huzaifa Sidhpurwala / Red Hat Product Security Team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: responding to CVEs
On 01/14/2019 09:38 PM, Kevin Kofler wrote: > Dave Love wrote: >> I ask because three CVEs have triggered automated bug reports against >> libxsmm <https://apps.fedoraproject.org/packages/libxsmm/bugs>. I don't >> understand why the CVEs were issued, since a problem with unrealistic >> input to a (rather rarely used) development tool doesn't strike me as a >> security problem. > > libxsmm is NOT a "development tool", it is a library that ends up linked > into scientific applications. Those applications may very well encounter > untrusted input, especially here where we are talking about importing > external files! So those security issues absolutely MUST be fixed! > Heap-based buffer overflows are indeed serious and if there is a patch, please apply it! Also no serious upstream will ignore these flaws, if they do , its not worth keeping these pkg in fedora imo! -- Huzaifa Sidhpurwala / Red Hat Product Security Team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Reminder: Package Maintainers please fix your security bugs!
On 09/05/2018 12:24 PM, Alexander Bokovoy wrote: > On Wed, 05 Sep 2018, Huzaifa Sidhpurwala wrote: >> Hi All, >> >> This is a gentle reminder for package maintainers to fix security bugs >> in the packages they maintain. A complete list of open security flaws >> against Fedora packages is available at: >> >> https://red.ht/2wJ8kLS >> >> Some documentation about this is also available at: >> https://fedoraproject.org/wiki/Security:HowtoSecurityBugs >> >> Remember as per the new policy, packages which fail to fix security >> bugs, will eventually be removed from the distribution. > There seems to be a set of bookkeeping issues with CVE bugzilla filings. > For example, for zziplib in F27 I closed yesterday a number of CVE > bugzillas that were not only fixed in February but also were out of > touch with the current package state across Fedora releases. > > I see a bunch of bugs being opened without really reviewing actual state > of software in Fedora. Claiming that something is unsupported and has to > be retired based on those bugs is then highly superficial. > This will definitely not happen. We will not retire packages based on flaws which are not really flaws. Trackers are opened by Product Security team against Fedora packages, by reviewing mostly the affected NVR etc, no detailed investigation is done. If you feel this is not really a bug feel free to close it. Package Maintainers know their packages more than anyone else. The purpose of this whole proposal is not to remove software from Fedora, but to achieve a state where open security issues are either addressed or appropriately closed if notaffected. -- Huzaifa Sidhpurwala / Red Hat Product Security Team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Reminder: Package Maintainers please fix your security bugs!
Hi All, This is a gentle reminder for package maintainers to fix security bugs in the packages they maintain. A complete list of open security flaws against Fedora packages is available at: https://red.ht/2wJ8kLS Some documentation about this is also available at: https://fedoraproject.org/wiki/Security:HowtoSecurityBugs Remember as per the new policy, packages which fail to fix security bugs, will eventually be removed from the distribution. Please get back to the security team via the mailing list (security-t...@lists.fedoraproject.org) or directly to me, if you have any questions! -- Huzaifa Sidhpurwala / Red Hat Product Security Team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: New policy for orphaning/retiring packages with open security bugs
On 09/04/2018 07:29 PM, Christian Stadelmann wrote: > How does one mark a bug as CRITICAL or IMPORTANT? > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > https://access.redhat.com/security/updates/classification contains the necessary details. Please let me know if you need more information! -- Huzaifa Sidhpurwala / Red Hat Product Security Team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Making Fedora secure - Package exit policy for security
On 08/01/2018 02:16 PM, Daniel P. Berrangé wrote: > On Wed, Aug 01, 2018 at 10:40:20AM +0530, Huzaifa Sidhpurwala wrote: >> On 07/31/2018 08:51 PM, Daniel P. Berrangé wrote: >> >>> >>> Do we have any analysis showing what would be the fallout if we applied >>> these purge rules today ? ie what packages would be dropped today due >>> to unaddressed CVEs. >>> >> See reply to my previous email. Also i have attached the list here. I >> did some random analysis and came up with the following conclusion: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1493497 >> This one is ftbs on ppc >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1488785 >> This one was actually fixed, but the bug did not close >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1487715 >> This is iamgemagick so one of many cves which are open against it. > > The list of ImageMagick CVEs is horrific - 59 open CVEs - for something > that is often going to be used in a scenario where it is fed untrustworthy > images. exiv2 is pretty concerning too with 19 open CVEs, again for > something often used with untrustworthy input images :-( > You havent seen ImageMagick issues yet :) I agree some of them cannot be fixed, because upstream did not fix them, but atleast there should be some mechanism or marking such pkgs as "has lot of CVEs use at your own risk". Not sure how, i havent thought about that yet. >>> Then, from that list of packages, do we have idea of reasons why >>> their CVEs are not getting fixed in Fedora. This could perhaps identify >>> changes to help with the problem(s), rather than jumping straight to >>> the big stick of dropping packages. >> >> I definitely want to address the core problem here, but i dont want to >> go through tens and even sometimes hundreds of bugs to figure out why >> they have not been fixed. Shouldnt the package maintainer be doing it in >> the first place? > > Obviously the responsibility lies with the package maintainer, but look > at what Fedora says their responsibility is: > > https://fedoraproject.org/wiki/Package_maintainer_responsibilities > > [quote] > Manage security issues > > Package maintainer should handle security issues quickly, and if they > need help they should contact the Security Response Team. > [/quote] > > The bugs we file against packages have big boilerplate text, but that's > focused around the mechanics of submitting updates, and again doesn't > give any guidance on how effectively triage the security bugs. > Those bugs are linked against "CVE bugs" which are filed against product-security component. The "CVE bugs" contain details, including patches, reproducers, upstream links etc. > Some maintainers are lucky enough to have experience of dealing with CVEs > from RHEL work, but many/most are not. The reality is much more nuanced > than "should handle security issues quickly". IMPORTANT and CRITICAL rated > security bugs must be handled on very different timeframe from LOW rated > bugs. The latter would be valid to just wait for a rebase in future Fedora > major release and mark CLOSED->UPSTREAM, while the former is something > you'd want to urgently backport fixes for into all existing releases. > MODERATE bugs get into a grey area where its hard to give a clear rule, > as urgency to fix them varies depending on usage context of the package. > In any case, putting a comment on the bug, with details like "No patch", "i am working on this one", or even "rebased in FEdora28, wont fix in f26" is fine! > So I can't put all blame on the package maintainers for failing to deal > with CVEs appropriately, when we're setting them up to fail by giving > little-to-no guidance on what's really expected in this area. > Shouldnt they ask for guidance then? I am happy to write docs/FAQs if there are any questions/comments. > That's obviously not the entire story here though - even with better docs, > I'm confident we'd still have a significant problem to consider. Some of > this may well be a result of maintainers simply having too many packages > to deal with. With the traditional "single owner" model of Fedora package > maint there's a tendancy to leave the fixing to the officially assigned > owner. For packages that we see a high volume of CVEs against, we perhaps > need to work ensure there are multiple maintainers recorded against the > package to give some redundancy. > How to do that? ie convince people to co-maintain pkgs with high CVE loads? given that cves are deterrent to pkg maintainers! > Regards, > Daniel > -- Huza
Re: Making Fedora secure - Package exit policy for security
On 08/01/2018 01:19 PM, Nikos Mavrogiannopoulos wrote: > On Tue, 2018-07-31 at 09:09 +0530, Huzaifa Sidhpurwala wrote: >> Hi All, >> >> I was asked to bring this issue[1] to the developer community before >> FESCO makes a decision. >> >> In several instances[2] there exists packages in Fedora, in which >> package-maintainers did not patch security issues, for multiple >> reasons >> including 1. non-responsive maintainer 2. issue hard to patch 3. no >> one >> cares? >> >> This is a risk for the distribution, our users and community as a >> whole >> and not to mentioned bad PR :) >> >> I would like to propose the following: >> >> >> 1. If a CRITICAL or IMPORTANT security issue is open against a >> package >> in Fedora-X and by the time X is EOL and the issue is not addressed, >> proactively remove the package from X+1 >> 2. If a MODERATE or LOW security issue is open against a package in >> Fedora -X and by the time X+! is EOL, the issue is not addressed, >> remove >> it from X+2 >> >> Note: >> 1. Once pkg is patches, it can be rebuild and re-introduced into the >> distro >> 2. X/X+1 is the best boundary to remove the insecure packages imo, >> since >> inbetween removals are not possible due to the way mirrors work. >> 3. Maintain a list somewhere (automated maybe) of the list of >> packages >> removed and why. >> 4. Have a list of critical pkg, which cannot be removed which will >> break >> the distro. >> >> The above is not set in stone, but is open for discussion. Let me >> know >> what you guys think! >> >> In the end, i would like you leave you all with this parting link: >> > > Thank you Huzaifa for bringing that up. I have a talk on fedora and > crypto in flock, and my recommendation will be towards having some > process to remove old packages from fedora. CVEs were not the drivers > there, but the continuous expansion of the crypto core which at the end > as you say causes CVEs which no-one addresses. To add to that, we ship > several packages which are the result of an internship, thesis, > packages which are there just in case and all expand the attack > surface. > > So yes, I'd support something like that, and even further than that, if > there is no update (upstream release) for 5 years, the > package+dependencies is marked for removal as well. Cancelling that > process would have to go through a fedora committee. > Thank you very much for supporting me on this. This proposal has come after years of experience in dealing with Security in Red Hat, upstream and Fedora itself. Honestly the volume of pkgs in Fedora is disturbing, more disturbing are fly-by maintainers, who do packaging for university projects etc and then disappear :( > regards, > Nikos > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JR7UNQKX2BSXNTGRSDRKWYDUA3U46V5I/ > -- Huzaifa Sidhpurwala / Red Hat Product Security Team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CM7I6AI2O777RQUJYRXUEYYENHT6JRJR/
Re: Making Fedora secure - Package exit policy for security
On 08/01/2018 01:41 PM, Daniel P. Berrangé wrote: > On Wed, Aug 01, 2018 at 10:33:11AM +0530, Huzaifa Sidhpurwala wrote: >> On 07/31/2018 08:33 PM, Rex Dieter wrote: >> >>>> 1. If a CRITICAL or IMPORTANT security issue is open against a package >>>> in Fedora-X and by the time X is EOL and the issue is not addressed, >>>> proactively remove the package from X+1 >>>> 2. If a MODERATE or LOW security issue is open against a package in >>>> Fedora -X and by the time X+! is EOL, the issue is not addressed, remove >>>> it from X+2 >>> >>> I don't think this is practical, we'll lose half the distro (are at least >>> large chunks). >>> >>> Initially, such a proposal may be possible if generally limited to leaf >>> packages. >>> >> >> So, i did some analysis of the number of packages which would be >> actually removed if we allowed this policy. I generated a list of open >> CVE bugs against X-2 which in this case is Fedora-26 and i got the >> following list: >> >> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=SecurityTracking%2C%20_type=allwords_id=9198136=Fedora_format=advanced=26 >> >> If you extract the list of components ,it yields 57 unique components. >> out of that components like xorg-server etc would probably be in the >> critical list. > > binutils is in the list, and without that, we won't have a distro at all ! > Yes, that is why the concept of critical pkgs, binutils and others would obviously be on that list, which means, they cannot be dropped from the distro. > Chances are though, that the bugs were fixed in upstream and so available > in newer Fedora version, so merely F26 left unfixed and the BZ status > outdated. I imagine this probably applies to most open CVEs against > RPMs which have an active upstream community. Its the ones with dead > upstream that and not fixed in Fedora that would be the serious concern. > If Newer fedora is fixed via rebase, the older trackers should be closed with appropriate resolution and comments. I am not asking all the security issues to be resolved in each version of fedora, i am merely asking for proper bookkeeping so that our users can make an informed decision. > Regards, > Daniel > -- Huzaifa Sidhpurwala / Red Hat Product Security Team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FENPZGAIFU5XSVXKQVNBZ2J457UHOSNV/
Re: Making Fedora secure - Package exit policy for security
On 07/31/2018 01:19 PM, Pavel Zhukov wrote: >> 1. If a CRITICAL or IMPORTANT security issue is open against a package >> in Fedora-X and by the time X is EOL and the issue is not addressed, >> proactively remove the package from X+1 > By the time FX is EOL'ed it's too late even for FX+2 to drop the > package. Besides of that CVE could be fixed in FX+2 but not fixed in FX > so the logic should be a way more complex. Sure, the above is just a proposal. We could perhaps drop it while FX+2 is beta etc. I am open to idea, as long as there is a way we could exit the package if it has a consistently bad security record. Also if CVE is fixed in FX+2 and will not be fixed in FX, the bug against FX should be closed as wontfix! >> 2. If a MODERATE or LOW security issue is open against a package in >> Fedora -X and by the time X+! is EOL, the issue is not addressed, remove >> it from X+2 > Same here. >> >> Note: >> 1. Once pkg is patches, it can be rebuild and re-introduced into the distro >> 2. X/X+1 is the best boundary to remove the insecure packages imo, since >> inbetween removals are not possible due to the way mirrors work. >> 3. Maintain a list somewhere (automated maybe) of the list of packages >> removed and why. >> 4. Have a list of critical pkg, which cannot be removed which will break >> the distro. >> >> The above is not set in stone, but is open for discussion. Let me know >> what you guys think! >> >> In the end, i would like you leave you all with this parting link: >> https://sensorstechforum.com/arch-linux-aur-repository-found-contain-malware/ >> >> [1] https://pagure.io/fesco/issue/1935 >> [2] >> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=SecurityTracking%2C%20_type=allwords_id=9076731=changeddate%2Cpriority%2Cbug_id=Fedora_based_on=_format=advanced -- Huzaifa Sidhpurwala / Red Hat Product Security Team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BXJFXBW4AX5B7QGM2NOS6CFFHSGLBADI/
Re: Making Fedora secure - Package exit policy for security
On 07/31/2018 05:05 PM, Ondřej Lysoněk wrote: > On 31.7.2018 05:39, Huzaifa Sidhpurwala wrote: >> I would like to propose the following: >> >> >> 1. If a CRITICAL or IMPORTANT security issue is open against a package >> in Fedora-X and by the time X is EOL and the issue is not addressed, >> proactively remove the package from X+1 >> 2. If a MODERATE or LOW security issue is open against a package in >> Fedora -X and by the time X+! is EOL, the issue is not addressed, remove >> it from X+2 >> >> Note: >> 1. Once pkg is patches, it can be rebuild and re-introduced into the distro >> 2. X/X+1 is the best boundary to remove the insecure packages imo, since >> inbetween removals are not possible due to the way mirrors work. >> 3. Maintain a list somewhere (automated maybe) of the list of packages >> removed and why. >> 4. Have a list of critical pkg, which cannot be removed which will break >> the distro. > Please make sure the process takes into account the fact that packages > may be affected by CVEs in certain Fedora releases only. For example an > older version of a package in F27 is affected by a CVE, but a new > (rewritten) version in F28 is not. It seems the summary of CVE bugs > accordingly contains either the string "[fedora-all]", or "[fedora-27]", > "[fedora-28]" etc. Hopefully that is a reliable source of information. > In this case, the CVE tracker should be fixed as CLOSED:WONTFIX, Automation will only look at open bugs! -- Huzaifa Sidhpurwala / Red Hat Product Security Team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Y3PSYRIVOMETQ67AGMQOBYHEKF73GHPR/
Re: Making Fedora secure - Package exit policy for security
On 07/31/2018 08:51 PM, Daniel P. Berrangé wrote: > > Do we have any analysis showing what would be the fallout if we applied > these purge rules today ? ie what packages would be dropped today due > to unaddressed CVEs. > See reply to my previous email. Also i have attached the list here. I did some random analysis and came up with the following conclusion: https://bugzilla.redhat.com/show_bug.cgi?id=1493497 This one is ftbs on ppc https://bugzilla.redhat.com/show_bug.cgi?id=1488785 This one was actually fixed, but the bug did not close https://bugzilla.redhat.com/show_bug.cgi?id=1487715 This is iamgemagick so one of many cves which are open against it. https://bugzilla.redhat.com/show_bug.cgi?id=1484840 Not sure. > Then, from that list of packages, do we have idea of reasons why > their CVEs are not getting fixed in Fedora. This could perhaps identify > changes to help with the problem(s), rather than jumping straight to > the big stick of dropping packages. > I definitely want to address the core problem here, but i dont want to go through tens and even sometimes hundreds of bugs to figure out why they have not been fixed. Shouldnt the package maintainer be doing it in the first place? > > Regards, > Daniel > -- Huzaifa Sidhpurwala / Red Hat Product Security Team apt-cacher-ng asterisk async-http-client binutils bzr chromium connman docker-distribution docker-latest emacs freerdp1.2 glpi hive ImageMagick itext jenkins-script-security-plugin ledger libmspack libsndfile lrzip mantis mercurial mesos mingw-binutils mingw-curl mingw-icu mingw-libgcrypt mingw-openjpeg2 mingw-openssl mingw-SDL2_image mongoose newsbeuter nodejs-debug nodejs-fresh nodejs-hawk nodejs-method-override nodejs-mime nodejs-st opencv openjpeg openjpeg2 opennlp passenger php php-Kohana python-scrapy resiprocate rtpproxy rubygem-ox rubygems sleuthkit springframework-amqp spring-ldap tcmu-runner tidy undertow xorg-x11-server ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/L62W4VXEJKI6RLUP6WPX5EPCT6Q7EE6H/
Re: Making Fedora secure - Package exit policy for security
On 07/31/2018 08:33 PM, Rex Dieter wrote: >> 1. If a CRITICAL or IMPORTANT security issue is open against a package >> in Fedora-X and by the time X is EOL and the issue is not addressed, >> proactively remove the package from X+1 >> 2. If a MODERATE or LOW security issue is open against a package in >> Fedora -X and by the time X+! is EOL, the issue is not addressed, remove >> it from X+2 > > I don't think this is practical, we'll lose half the distro (are at least > large chunks). > > Initially, such a proposal may be possible if generally limited to leaf > packages. > So, i did some analysis of the number of packages which would be actually removed if we allowed this policy. I generated a list of open CVE bugs against X-2 which in this case is Fedora-26 and i got the following list: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=SecurityTracking%2C%20_type=allwords_id=9198136=Fedora_format=advanced=26 If you extract the list of components ,it yields 57 unique components. out of that components like xorg-server etc would probably be in the critical list. So overall, i dont think its a big problem imo. Theoretically if there is an FTBS, the maintainer would definitely want to do something to fix this. Maybe a lot of these bugs are not really applicable or a rebase already fixed them, so all that is required is to close the bug with an approproate explanation. -- Huzaifa Sidhpurwala / Red Hat Product Security Team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7X4LIFJD7NTJN4A4Z3JYJPI43SBL7RGA/
Making Fedora secure - Package exit policy for security
Hi All, I was asked to bring this issue[1] to the developer community before FESCO makes a decision. In several instances[2] there exists packages in Fedora, in which package-maintainers did not patch security issues, for multiple reasons including 1. non-responsive maintainer 2. issue hard to patch 3. no one cares? This is a risk for the distribution, our users and community as a whole and not to mentioned bad PR :) I would like to propose the following: 1. If a CRITICAL or IMPORTANT security issue is open against a package in Fedora-X and by the time X is EOL and the issue is not addressed, proactively remove the package from X+1 2. If a MODERATE or LOW security issue is open against a package in Fedora -X and by the time X+! is EOL, the issue is not addressed, remove it from X+2 Note: 1. Once pkg is patches, it can be rebuild and re-introduced into the distro 2. X/X+1 is the best boundary to remove the insecure packages imo, since inbetween removals are not possible due to the way mirrors work. 3. Maintain a list somewhere (automated maybe) of the list of packages removed and why. 4. Have a list of critical pkg, which cannot be removed which will break the distro. The above is not set in stone, but is open for discussion. Let me know what you guys think! In the end, i would like you leave you all with this parting link: https://sensorstechforum.com/arch-linux-aur-repository-found-contain-malware/ [1] https://pagure.io/fesco/issue/1935 [2] https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=SecurityTracking%2C%20_type=allwords_id=9076731=changeddate%2Cpriority%2Cbug_id=Fedora_based_on=_format=advanced -- Huzaifa Sidhpurwala / Red Hat Product Security Team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZCM54WM3WYZAJ3MXAOXJHLZCUGZONN3F/
Re: F22 System Wide Change: Enable Polyinstantiated /tmp and /var/tmp directories by default
On 01/20/2015 05:59 PM, Lennart Poettering wrote: Well, /tmp is used by X11 among other for IPC across user boundaries. If you give each other their private instance of it, they cannot use this for communication anymore. You are breaking X11 this way. Did you read the attached references to the proposal? X11 is a special case of needed a shared temp. directory between root and a no-root process. The reference has a way to solve this problem. afaik, non-root xorg wont need this hack anymore. Moreover, if you want to give each user a private instance of /tmp you have to run that user in a private mount namespace and disable propagation from that namespace into the host for the / directory for this. (After all the /tmp over-mounting shall be private to the user, and not propagate to the rest of the system.) This of course means that if the user later-on invokes /bin/mount or /bin/umount on any subdir of / the commands have will have zero effect for the rest of the system. You pretty much brek mounting/umounting for normal users. If you do this, pretty much every admin will hate you deeply. Also, introducing /tmp-inst sounds really wrong to me, what's the point of that? systemd's PrivateTmp= works by mounting /tmp over with a subdir of /tmp, so that things stay on the same file system. Why introduce a new directory? /tmp-inst is created with mode 000, as compared to /tmp. As per the documentation pam_namespace will enforce this mode, unless explicitly asked to bypass this. How do you intend for the new /tmp instance to be life-cycled? When is the private /tmp instance removed? On logout? Tracking a user session's lifecycle is not easy, as the user might have processes running that are not attached to any session, and you shouldn't remove the private /tmp before those processes are dead too. Private tmp instances are NOT removed. Only access to them is restricted to process which run as the $user. To me this sounds very much not thought to the end. Maybe you should try doing this once and see how it scales? We thought a couple of times in adding an option for this to systemd/logind, after all, we have the namespacing code in systemd anyway, and we can at least track the sessions through logind very precisely. However, X11 and the mount propagation breakage are real blockers to make this useful in the general case. This idea can only fly for very special systems where the propagation is irrelevant. It's not compatible with admin workflows, at all. Lennart -- Huzaifa Sidhpurwala / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: usb-modeswitch/usb-modeswitch-data must be updated (hardware related)
I will update both the components today. Thanks! - Original Message - From: Xose Vazquez Perez xose.vazq...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Monday, October 24, 2011 10:00:58 PM Subject: usb-modeswitch/usb-modeswitch-data must be updated (hardware related) https://bugzilla.redhat.com/show_bug.cgi?id=728680 https://bugzilla.redhat.com/show_bug.cgi?id=625004 == usb-modeswitch-1.2.0 == Version 1.2.0, 2011/10/23 Added QisdaMode for Qisda H21 (thanks to Chi-Hang Long for the code); dispatcher can now be installed with an embedded interpreter, so that Tcl is no longer required; added command line options for binary program to accept configuration data via stdin or as a long string parameter - this fixes the bug with non-writable temporary file during boot; reversed skipping of pre-switching delay, which has caused problems; fixed potential buffer overflow (thanks to Rafael Silva for the find); get first interface right even on some broken devices (thanks to Alexander Gordeev for the patch); increased post-switch delay before driver binding to avoid conflict with usb-storage - == usb-modeswitch-data-20111023 == 20111023: Added devices: C-motech CDU-685a, Qisda H21 Flying Beetle (needs program version = 1.2.0) 20111012: Added devices: AnyDATA APE-540H, ZTE MF192 (new variant) 20111007: Added devices: Alcatel OT X220L, Nokia CS-19, Huawei ET302, 3GO 3GO11 HSUPA, Novatel MC545, ZTE AC682, ZTE MF820 4G LTE, Philips PicoPix 1020 (LED projector); added some ZTE target IDs; modded udev rules to include change as trigger event 20110805: Added devices: Vodafone/Huawei K4510 K4511, Vodafone/ZTE K3770-Z, K3772-Z and K4510-Z (thanks to Andrew Bird); five Option HSO modems; Cisco Valet AM10 (use with program version = 1.1.9) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: usb_modeswitch/usb_modeswitch-data outdated
On 07/25/2011 07:17 AM, Kevin Fenzi wrote: Do file a bug to alert the maintainer(s) that they should update and why. taken care of this, sorry for the delay :) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: NetworkManager to reconnect silently
Is there a way to tell NM not to ask for a new password ever? Because I use a 63-symbol passphrase once set up on all the (two) machines so to forget about it. Store the password in gnome-keyring-manager? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: WebKit(s) SIG
Hi, If you're interested in - please reply, I'd like to start Wiki page and we can talked about more details etc. Count me in :) Regards, Huzaifa Sidhpurwala -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gethostbyname() and resolv.conf updates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bernie Innocenti wrote: Hello, xchat in Fedora needs to be restarted after switching to a different nameserver or it fails to resolve. The xchat developers say that all xchat does is call gethostbyname(). A Debian user told me that Debian carries a glibc patch to make processes notice resolv.conf updates and reload it. Is there any chance we could apply the same patch in Fedora too? I don't know all the details, but I guess there might be a good reason why this patch wasn't upstreamed yet. I dont think we should patch glibc, unless its upstream. Looking at the thread at: http://sources.redhat.com/ml/libc-alpha/2004-09/msg00109.html it does not appear this patch would make it upstream though. - -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org/ iD8DBQFMGudszHDc8tpb2uURApicAJsFY4D+T59/oLPCMpsPuYMQX4xVVACeK589 3YToGCKcXX0OO8OkqKJJlw8= =USCv -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: usb_modeswitch 1.1.2 in Fedora 11
Hi Bernie, Works for me, Since you are already a provenpackager i dont think you need explicit cvs access on that package, so i would say go ahead and thanks for doing it. Regards, Huzaifa Sidhpurwala. - Original Message - From: Bernie Innocenti ber...@codewiz.org To: Huzaifa Sidhpurwala huzai...@redhat.com Cc: Fedora Development fedora-devel-l...@redhat.com Sent: Fri, 7 May 2010 16:13:49 -0400 (EDT) Subject: usb_modeswitch 1.1.2 in Fedora 11 You appear to be the maintainer of usb_modeswitch. For the purpose of making GSM connectivity work on the OLPC XO-1, I've backported usb_modeswitch and usb_modeswitch-data to Fedora 11. It's been tested in the field and it fixes some Huawei models that were previously unusable. Would you mind if I pushed this update before the Fedora 11 repositories freeze? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New improved usb_modeswitch coming your way !!
David Woodhouse wrote: On Wed, 2010-04-21 at 14:03 +0530, Huzaifa Sidhpurwala wrote: I would rather patch the tcl script to use the binary in /usr/bin :) Unless people thing otherwise. Why deviate from what upstream does, which is to use /usr/sbin? This is fixed now in https://admin.fedoraproject.org/updates/usb_modeswitch-1.1.2-3.fc13 https://admin.fedoraproject.org/updates/usb_modeswitch-1.1.2-3.fc12 Thanks for the inputs. -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
New improved usb_modeswitch coming your way !!
Hi All, So i split up usb_modeswitch into the main package and the data part, now called usb_modeswitch and usb_modeswitch-data. The version in testing is latest upstream 1.1.2. It would be great if any one using usb_modeswitch could test this version as well and give it a karma :) https://admin.fedoraproject.org/updates/usb_modeswitch-1.1.2-1.fc12,usb_modeswitch-data-20100418-2.fc12 https://admin.fedoraproject.org/updates/usb_modeswitch-data-20100418-2.fc13,usb_modeswitch-1.1.2-1.fc13 -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New improved usb_modeswitch coming your way !!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Woodhouse wrote: On Wed, 2010-04-21 at 12:15 +0530, Huzaifa Sidhpurwala wrote: So i split up usb_modeswitch into the main package and the data part, now called usb_modeswitch and usb_modeswitch-data. The version in testing is latest upstream 1.1.2. It would be great if any one using usb_modeswitch could test this version as well and give it a karma :) Might work better if you set $bindir to /usr/bin in the /lib/udev/usb_modeswitch script. Or did you mean to move the usb_modeswitch binary from /usr/bin to /usr/sbin in the packaging? I would rather patch the tcl script to use the binary in /usr/bin :) Unless people thing otherwise. (I tested the F-12 version) - -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org/ iD8DBQFLzrh3zHDc8tpb2uURAjf0AJ0QU1SDX9dxLeL9J3ann9KI2lI8yACfbgK9 PgMJega1vkNXhCoYViEwWek= =mBB1 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Query about usb_modeswitch and how to handle its packaging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All, I maintain usb-modeswitch in fedora. Recently upstream divided the main tar ball into two parts, the code which builds into the usb_modeswitch binary and the data part which contains the udev rules. Initially there was just one tar ball with both, and my spec builds two rpms out of that namely usb_modeswitch and usb_modeswitch-data. Now upstream says that his intention of making two tar balls was to enable updating the data part more frequently then the code, which makes sense. Now i have two options: 1. Have just one srpm, which builds from the two tar balls, if that is done, the upstream purpose of updating the data more frequently is lost. Also upstream says usb_modeswitch has to depend on usb_modeswitch-data and vice versa. 2. Have two srpms one for data and one for binary, with both depending on each other. Which one do you think is the best option. Thanks in advance. - -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org/ iD8DBQFLzV31zHDc8tpb2uURAjVxAJ40ie5HVcrADk5qaSmsS6687dhWUwCgjdHO mdulXkdmkcHt/l4emO+L0JY= =y/O9 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Using capabilities for libpcap apps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I was speaking about this with Rahul Sundaram and he pointed me to: http://fedoraproject.org/wiki/Features/LowerProcessCapabilities I would suggest using libpcap-ng rather than libpcap if it works. Radek Vokál wrote: Hi all, I need few suggestions about this .. https://blog.wireshark.org/2010/02/running-wireshark-as-you/ .. Gerald Combs, the upstream maintainer of wireshark, suggests to use capabilities instead of consolehelper+root privileges for dumpcap/wireshark. It makes whole lot of sense, so I've looked if other apps in Fedora are already using it and I haven't found any. Honestly I'm not sure about right way to use them. The idea is to add something like following to %post # groupadd -g wireshark # chgrp wireshark /usr/bin/dumpcap # setcap cap_net_raw,cap_net_admin+eip /usr/bin/dumpcap # setcap cap_net_raw,cap_net_admin+eip /usr/bin/tshark Suggestions? Ideas? Spec file patches? Any help is welcome. Radek - -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org/ iD8DBQFLvCbzzHDc8tpb2uURAhmUAJ9m3DzIXyuF5Q87RsRTwWN94KZiYQCfQuAn gPmMlJxwAKWCGyQJoCBbpSw= =Wkq8 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Using capabilities for libpcap apps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Huzaifa Sidhpurwala wrote: Ah Sorry, scratch the last line please, an oversight :) I would suggest using libpcap-ng rather than libpcap if it works. - -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org/ iD8DBQFLvCeAzHDc8tpb2uURAlpdAJ9+BCrK1bdIlxhVvClowrxcpgnM6ACeJ+m9 z3Nec3oCE70JFCf5EqnpbF0= =ZK2e -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: usb_modeswitch by default
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rahul Sundaram wrote: Just to clarify, does ModemManager need to depend on usb_modeswitch? It currently does not. Dan, I guess its not such a bad idea to make it depend? Rahul - -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org/ iD8DBQFLqDMazHDc8tpb2uURAqpAAKCR3Nf3HtEbcGI3FiXvgKqF4xEqyQCfcrNL JQqNaOS8dvbtcDYdjLXeh3E= =NbZv -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Maxim Burgerhout wrote: I wouldn't mind doing dash, but as I am a relatively new packager and this is a critical path package, (more experienced) co-maintainers would be very welcome. I would like to co-maintain dash as well, as if that is ok. Maxim Burgerhout ma...@wzzrd.com GPG Fingerprint EB11 5E56 E648 9D99 E8EF 05FB C513 6FD4 1302 B48A On Wed, Mar 17, 2010 at 21:35, Rahul Sundaram methe...@gmail.com wrote: On 03/18/2010 02:01 AM, Jon Ciesla wrote: Warren Togami wrote: I am orphaning the following packages. Two look pretty important for someone else to save. NEWLY ORPHANED PACKAGES = dash (critical path, used by dracut) scponly (pretty important!) Trying to take scponly, I keep getting Request Failed. Same here. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel - -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) IT Desktop RD Lead. Global Help Desk, Pune (India) Phone: +91 20 4005 7322 (UTC +5.5) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org/ iD8DBQFLobPHzHDc8tpb2uURAjE/AJ9ifYCwhiXAt1KYrvW1oZiuMYaM7QCfdc4I CmlWVEaD7SavIeGNZ3gBDhM= =JNYA -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: usb_modeswitch by default
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I have taken over the maintainership from Robert, and the new usb_modeswitch rpms are in rawhide now. Let me know if you guys need anything fixed on that :) - -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) IT Desktop RD Lead. Global Help Desk, Pune (India) Phone: +91 20 4005 7322 (UTC +5.5) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org/ iD8DBQFLkISxzHDc8tpb2uURAsdHAJoCyhKEzDTxkC03/AwefsL578zElgCcDrKc mGa1DCfedKxhBZ7hfEm2Tks= =huTr -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Sindre Pedersen Bjørdal is AWOL, 25 packa ges looking for new owners
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * firewalk -- Active reconnaissance network security tool * httptunnel -- Tunnels a data stream in HTTP requests * nikto -- Web server scanner Taken these :) - -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org/ iD8DBQFLaPMPzHDc8tpb2uURAmFMAJ9uwqayxwDB3tcYYJ+UO7h1m2YxAACfRs5t 2fOzhP3pTtqGEZ/CkVPnO0I= =W6fc -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
