Re: /sbin/nologin in /etc/shells
2016-09-29 16:58 GMT+02:00 Stephen John Smoogen : > https://www.stigviewer.com/stig/vmware_esxi_v5/2013-01-15/finding/GEN002140-ESXI5-46 This is titled "All shells referenced in /etc/passwd must be listed in the /etc/shells file, except any shells specified for the purpose of preventing logins." and *doesn't* require /sbin/nologin to be in /etc/shells, or am I misreading it? - Thomas ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: /sbin/nologin in /etc/shells
On Thu, Sep 29, 2016 at 9:58 PM, Kevin Kofler wrote: > Stephen John Smoogen wrote: >> Well that boat sailed in 2001... so have you been removing it from >> your /etc/shells in the last 15 years? > > No, because I was not aware that Fedora had been shipping with this security > hole for 15 years! Of course I immediately fixed it upon reading this > thread. Because you were not on the deck waving to people on shore did not mean the boat did not sail. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: /sbin/nologin in /etc/shells
On 9/29/2016 5:55 PM, Kevin Kofler wrote: Nobody should ever add this at all. And most definitely not Fedora. The behavior the original poster pointed out: | - su -s /bin/bash - nologinuser (if "nologinuser" has /sbin/nologin as the | default shell) succeeds with /bin/bash if auth is successful [2], even | though man 1 su, man 8 nologin, and man 5 shells suggest that such a user | is a restricted user and logging in with an alternate specified shell | should be forbidden. sounds very much like a critical privilege escalation security hole to me, that should get a CVE and be fixed in all supported Fedora releases ASAP! How is this a "critical...security hole"? I seriously can't be the only person out there that intentionally sets accounts to /sbin/nologin if they don't need to log in (as another layer of security), but occasionally runs 'su -s /bin/my/shell/of/choice uid' when I need to do some work under it, can I? In any event, this has been this way for 14 years. There are legitimate reasons for wanting a "valid" shell that, nevertheless, results in disallowing remote logins in a human-readable way. The traditional solution IIRC had been to set someone's shell to /bin/false, but I fail to see why -- 14 years later -- this is something I need to get a warning about, let alone something to be considered an actual problem. A sysadmin who runs "usermod -s /sbin/nologin" knows what they're doing. If, as mentioned at https://bugzilla.redhat.com/show_bug.cgi?id=53963#c7, it didn't cause a problem in the first two years, "fixing" it 12 years after that seems unnecessary. We "fix" enough perfectly-working stuff in Fedora as it is... +1 to fixing this by updating the shells man page as indicated in https://bugzilla.redhat.com/show_bug.cgi?id=1218302#c4 Regards, -jc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: /sbin/nologin in /etc/shells
On 29 September 2016 at 21:58, Kevin Kofler wrote: > Stephen John Smoogen wrote: >> Well that boat sailed in 2001... so have you been removing it from >> your /etc/shells in the last 15 years? > > No, because I was not aware that Fedora had been shipping with this security > hole for 15 years! Of course I immediately fixed it upon reading this > thread. > But did you fix it? Does removing it from /etc/shells stop the su - -s/bin/bash ? [Because it doesn't seem to] Did removing it fix any of the other concerns you had? > Kevin Kofler > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: /sbin/nologin in /etc/shells
Stephen John Smoogen wrote: > Well that boat sailed in 2001... so have you been removing it from > your /etc/shells in the last 15 years? No, because I was not aware that Fedora had been shipping with this security hole for 15 years! Of course I immediately fixed it upon reading this thread. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: /sbin/nologin in /etc/shells
On 29 September 2016 at 20:55, Kevin Kofler wrote: > Stephen John Smoogen wrote: >> One of the reasons for it to be in /etc/shells was that various audit >> systems failed an OS if it wasn't. [Various government and bank >> security audit tools have rules like >> https://www.stigviewer.com/stig/vmware_esxi_v5/2013-01-15/finding/GEN002140-ESXI5-46 >> ] The second reason was that outside scripts would fail because chsh >> was giving an 'error' that nologin was not there. > > So the audit tools REQUIRE you to add a critical security hole? > Yep. Been that way for multiple audit curriculum since the 1980's (Orange Book?) ? I have seen it in everything from banks, to NATO, to .gov, to scientific systems which were going to EU labs. I expect some amount of it is cargo cult but it is what it is currently. I have enough Sisyphus tasks on my plate already to add this to it. >> While it can be argued that these are problems with other parties what >> was happening is that they haven't been fixed in multiple years and >> everyone who had to have anything from a PCI to a .gov audit had to go >> put this in the file already. This basically then becomes a "do you >> need to manually add this on the system? [Y/N]" purchase checkmark for >> banks, credit card processors, government contractors. > > Nobody should ever add this at all. And most definitely not Fedora. Well that boat sailed in 2001... so have you been removing it from your /etc/shells in the last 15 years? > > The behavior the original poster pointed out: > | - su -s /bin/bash - nologinuser (if "nologinuser" has /sbin/nologin as the > | default shell) succeeds with /bin/bash if auth is successful [2], even > | though man 1 su, man 8 nologin, and man 5 shells suggest that such a user > | is a restricted user and logging in with an alternate specified shell > | should be forbidden. > sounds very much like a critical privilege escalation security hole to me, > that should get a CVE and be fixed in all supported Fedora releases ASAP! I am not sure you would get a CVE on it as much as a "It is working as it has been working for 30 years... fix the man page" I don't think it is privilege escalation because the person needs to know the account with /sbin/nologins password and they need to have shell access to the system somehow. They aren't getting root, but only to something that a password was set AND they have been allowed access to a shell on the system even as a different user you have other problems already. -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: /sbin/nologin in /etc/shells
Stephen John Smoogen wrote: > One of the reasons for it to be in /etc/shells was that various audit > systems failed an OS if it wasn't. [Various government and bank > security audit tools have rules like > https://www.stigviewer.com/stig/vmware_esxi_v5/2013-01-15/finding/GEN002140-ESXI5-46 > ] The second reason was that outside scripts would fail because chsh > was giving an 'error' that nologin was not there. So the audit tools REQUIRE you to add a critical security hole? > While it can be argued that these are problems with other parties what > was happening is that they haven't been fixed in multiple years and > everyone who had to have anything from a PCI to a .gov audit had to go > put this in the file already. This basically then becomes a "do you > need to manually add this on the system? [Y/N]" purchase checkmark for > banks, credit card processors, government contractors. Nobody should ever add this at all. And most definitely not Fedora. The behavior the original poster pointed out: | - su -s /bin/bash - nologinuser (if "nologinuser" has /sbin/nologin as the | default shell) succeeds with /bin/bash if auth is successful [2], even | though man 1 su, man 8 nologin, and man 5 shells suggest that such a user | is a restricted user and logging in with an alternate specified shell | should be forbidden. sounds very much like a critical privilege escalation security hole to me, that should get a CVE and be fixed in all supported Fedora releases ASAP! Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
devel@lists.fedoraproject.org
On Thu, 2016-09-29 at 16:51 -0600, Chris Murphy wrote: > But I don't > think QA clearly understands what cloud image(s) are release blocking, > as previously they were just the non-atomic images. I don't know what's going on with all this crap, but so far as I'm concerned I understand perfectly well what the release blocking images are. It's the ones listed on the release blocking images page which specifically exists for this purpose: https://fedoraproject.org/wiki/Fedora_Program_Management/ReleaseBlocking/Fedora25 (we still need to make the canonical version of this a JSON file somewhere and generate the human-readable version from the JSON, but meh, I haven't got around to it yet). if it doesn't say 'yes' there, it ain't release blocking. Maintaining that thing is the program manager's problem (i.e. jkurik's), not mine, but it does somewhat concern me the number of 'TBD's on there. I don't think the question of what images are 'release blocking' for F25 should be *remotely* live at this point: it should have been decided weeks ago, at least by Alpha release. And so far as I remember it, that's what the protocol was supposed to be, we weren't still supposed to be kicking around 'is it blocking?' discussions at Beta freeze. I'd personally be very unhappy with any attempt to significantly change what that page says right now. Which images are prominent on the download pages and how much of a relationship there is between that and 'release blocking' status is *also* not my problem, but I'd agree with you (Chris) that it'd be rather strange for the most prominently advertised deliverable for a given product not to be a release-blocking one. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
devel@lists.fedoraproject.org
On Thu, Sep 29, 2016 at 4:32 PM, Chris Murphy wrote: > Also I read in the Fedora magazine meeting that just wrapped up 30 > minutes ago, that Atomic is the default for F25 (among Cloud > deliverables). To my ears, "default" and "primary" download sound like > they'd be release blocking. And the point of that is what bugs would > block release, what criteria apply or not, to that deliverable. Maybe default download is orthogonal to release blocking status - even though off hand to me that seems like an odd duck. And it looks like it'd be the QCOW2 image that's the propose default, not the ISO (which uses anaconda, and there are still bugs that would be blocker worthy if it's the release blocking image). But I don't think QA clearly understands what cloud image(s) are release blocking, as previously they were just the non-atomic images. Other than that I think I'm fairly well sorted out for now. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 25-20160927.n.0 compose check report
Missing expected images: Xfce raw-xz armhfp Cloud_base raw-xz i386 Failed openQA tests: 3/102 (x86_64), 1/17 (i386), 1/2 (arm) New failures (same test did not fail in 25-20160926.n.0): ID: 37372 Test: arm Minimal-raw_xz-raw.xz base_services_start_arm URL: https://openqa.fedoraproject.org/tests/37372 ID: 37374 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller URL: https://openqa.fedoraproject.org/tests/37374 Old failures (same test failed in 25-20160926.n.0): ID: 36529 Test: x86_64 Atomic-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/36529 ID: 36589 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/36589 ID: 36630 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/36630 Soft failed openQA tests: 1/102 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test did not softfail in 25-20160926.n.0): ID: 36531 Test: x86_64 KDE-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/36531 Passed openQA tests: 97/102 (x86_64), 16/17 (i386), 1/2 (arm) New passes (same test did not pass in 25-20160926.n.0): ID: 36524 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/36524 ID: 36592 Test: x86_64 universal install_simple_free_space@uefi URL: https://openqa.fedoraproject.org/tests/36592 ID: 36603 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/36603 ID: 36604 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/36604 ID: 36610 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/36610 ID: 37371 Test: i386 Workstation-live-iso install_default URL: https://openqa.fedoraproject.org/tests/37371 ID: 37373 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/37373 -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
devel@lists.fedoraproject.org
OK my confusion definitely reduced but still some remains and they may only be trivial details: Cloud WG has explicitly mentioned an Atomic WG more than once, most recently yesterday 17:40:46 #topic Open Floor 17:41:07 what about making the Atomic WG? [...snip...] 17:42:45 sayan: I assumed that was a given https://meetbot.fedoraproject.org/teams/fedora_cloud_wg/fedora_cloud_wg.2016-09-28-17.00.log.html Also I read in the Fedora magazine meeting that just wrapped up 30 minutes ago, that Atomic is the default for F25 (among Cloud deliverables). To my ears, "default" and "primary" download sound like they'd be release blocking. And the point of that is what bugs would block release, what criteria apply or not, to that deliverable. And in the previous meeting a week ago: 17:14:15 here's a draft from the designer: https://raw.githubusercontent.com/fedoradesign/nextweb-assets/master/Mockups/Brochure%20Site/brochure-mock-atomic_WIP.png 17:14:23 sayan: I can't answer that. someone else has to 17:15:37 the mockup looks good to me 17:16:06 jberkus, looks nice 17:16:12 just so everyone's up to date, the problem is that this redesign orphans the AWS picker for Cloud base images (as opposed to Atomic) 17:16:21 I like it 17:16:22 +1 17:16:29 presumably that now needs to live somewhere on Server 17:16:42 but someone more central to Fedora than me needs to take it to them 17:16:48 So, is cloud base going to server for 25? Or is that 26? 17:17:03 25 https://meetbot.fedoraproject.org/fedora-meeting-1/2016-09-21/fedora_cloud_wg.2016-09-21-17.00.log.html But then in the Server meeting this week, taking on cloud images was discussed in the context of Fedora 26, not Fedora 25. So... if I'm spreading confusion or focusing on details that don't matter that much, most definitely throw tomatoes (preferably heirloom or a nice red field). Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Rawhide-20160929.n.1 compose check report
On Thu, 2016-09-29 at 22:15 +, Fedora compose checker wrote: > Missing expected images: > > Kde live i386 > Workstation live i386 > Kde live x86_64 > Cloud_base raw-xz x86_64 > Cloud_base raw-xz i386 > Kde raw-xz armhfp > Minimal raw-xz armhfp > Workstation live x86_64 > > Failed openQA tests: 49/79 (x86_64), 11/15 (i386) There's some craziness going on causing a bunch of weird dependency errors, which makes most of the tests fail (and some images fail to build). releng is looking into it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Rawhide-20160929.n.1 compose check report
Missing expected images: Kde live i386 Workstation live i386 Kde live x86_64 Cloud_base raw-xz x86_64 Cloud_base raw-xz i386 Kde raw-xz armhfp Minimal raw-xz armhfp Workstation live x86_64 Failed openQA tests: 49/79 (x86_64), 11/15 (i386) ID: 37282 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/37282 ID: 37283 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/37283 ID: 37289 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/37289 ID: 37290 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/37290 ID: 37299 Test: x86_64 Server-dvd-iso install_updates_nfs URL: https://openqa.fedoraproject.org/tests/37299 ID: 37302 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/37302 ID: 37303 Test: x86_64 universal install_package_set_minimal URL: https://openqa.fedoraproject.org/tests/37303 ID: 37304 Test: x86_64 universal install_anaconda_text URL: https://openqa.fedoraproject.org/tests/37304 ID: 37306 Test: x86_64 universal install_repository_http_variation URL: https://openqa.fedoraproject.org/tests/37306 ID: 37307 Test: x86_64 universal install_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/37307 ID: 37308 Test: x86_64 universal install_mirrorlist_graphical URL: https://openqa.fedoraproject.org/tests/37308 ID: 37309 Test: x86_64 universal install_delete_pata URL: https://openqa.fedoraproject.org/tests/37309 ID: 37310 Test: x86_64 universal install_delete_pata@uefi URL: https://openqa.fedoraproject.org/tests/37310 ID: 37311 Test: x86_64 universal install_kickstart_user_creation URL: https://openqa.fedoraproject.org/tests/37311 ID: 37312 Test: x86_64 universal install_scsi_updates_img URL: https://openqa.fedoraproject.org/tests/37312 ID: 37313 Test: x86_64 universal install_multi URL: https://openqa.fedoraproject.org/tests/37313 ID: 37314 Test: x86_64 universal install_multi@uefi URL: https://openqa.fedoraproject.org/tests/37314 ID: 37315 Test: x86_64 universal install_simple_encrypted URL: https://openqa.fedoraproject.org/tests/37315 ID: 37316 Test: x86_64 universal install_simple_free_space URL: https://openqa.fedoraproject.org/tests/37316 ID: 37317 Test: x86_64 universal install_multi_empty URL: https://openqa.fedoraproject.org/tests/37317 ID: 37318 Test: x86_64 universal install_software_raid URL: https://openqa.fedoraproject.org/tests/37318 ID: 37319 Test: x86_64 universal install_delete_partial URL: https://openqa.fedoraproject.org/tests/37319 ID: 37320 Test: x86_64 universal install_btrfs URL: https://openqa.fedoraproject.org/tests/37320 ID: 37321 Test: x86_64 universal install_ext3 URL: https://openqa.fedoraproject.org/tests/37321 ID: 37322 Test: x86_64 universal install_xfs URL: https://openqa.fedoraproject.org/tests/37322 ID: 37323 Test: x86_64 universal install_lvmthin URL: https://openqa.fedoraproject.org/tests/37323 ID: 37324 Test: x86_64 universal install_no_swap URL: https://openqa.fedoraproject.org/tests/37324 ID: 37325 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/37325 ID: 37326 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/37326 ID: 37327 Test: x86_64 universal install_simple_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/37327 ID: 37328 Test: x86_64 universal install_simple_free_space@uefi URL: https://openqa.fedoraproject.org/tests/37328 ID: 37329 Test: x86_64 universal install_multi_empty@uefi URL: https://openqa.fedoraproject.org/tests/37329 ID: 37330 Test: x86_64 universal install_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/37330 ID: 37331 Test: x86_64 universal install_delete_partial@uefi URL: https://openqa.fedoraproject.org/tests/37331 ID: 37332 Test: x86_64 universal install_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/37332 ID: 37333 Test: x86_64 universal install_ext3@uefi URL: https://openqa.fedoraproject.org/tests/37333 ID: 37334 Test: x86_64 universal install_xfs@uefi URL: https://openqa.fedoraproject.org/tests/37334 ID: 37335 Test: x86_64 universal install_lvmthin@uefi URL: https://openqa.fedoraproject.org/tests/37335 ID: 37336 Test: x86_64 universal install_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/37336 ID: 37337 Test: x86_64 universal install_kickstart_hdd URL: https://openqa.fedoraproject.org/tests/37337 ID: 37341 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/37341 ID: 37342 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/37342 ID: 37348 Test: x86_64
Re: Cannot build live iso using livemedia-creator
On Thu, 2016-09-29 at 15:08 -0700, Adam Williamson wrote: > > That error means the anaconda install failed. The way livemedia_creator > works is that it actually runs an anaconda install using the kickstart > specified - using its 'install to a directory' method if you pass --no- > virt, otherwise in a VM - then creates an image file from the resulting > installation. ...well, okay, that's a lie. It actually creates the image file, then either attaches it to a VM and runs the install in the VM (virt mode) or mounts it and runs an anaconda directory install into the mounted path (novirt mode), so either way, the image now contains an installed system. Once anaconda is done it twiddles about a bit more with the image. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Cannot build live iso using livemedia-creator
On Thu, 2016-09-29 at 15:34 -0300, Sergio Belkin wrote:
> Hi,
>
> I've tried to create a Live ISO using livemedia-creator, and followed the
> steps from
> https://fedoraproject.org/wiki/Livemedia-creator-_How_to_create_and_use_a_Live_CD
> .
>
> But I cannot do it, these is the errors:
>
> sudo livemedia-creator --ks
> /home/sergio/Descargas/Pagure/flat-fedora-live-base.ks --no-virt
> --resultdir /home/lmc --project Fedora-Rescate-Silicon --make-iso --volid
> Fedora24-Rescate-Silicon --iso-only --iso-name F24-R-R-Silicon.iso
> /usr/lib64/python3.5/optparse.py:999: PendingDeprecationWarning: The
> KSOption class is deprecated and will be removed in pykickstart-3. Use the
> argparse module instead.
> option = self.option_class(*args, **kwargs)
> 2016-09-29 15:23:19,900: disk_img = /home/lmc/lmc-disk-flpdk287.img
> 2016-09-29 15:23:19,901: Using disk size of 5122MiB
> 2016-09-29 15:23:22,380: Running anaconda.
> 2016-09-29 15:23:24,103: Processing logs from ('127.0.0.1', 51634)
> 2016-09-29 15:23:27,388: The 'logging' function is not a part of DNF API
> and will be removed in the upcoming DNF release. Please use only officially
> supported API functions. DNF API documentation is available at
> https://dnf.readthedocs.org/en/latest/api.html.
> 2016-09-29 15:23:27,388: Starting installer, one moment...
> 2016-09-29 15:23:27,389: terminal size detection failed, using default width
> 2016-09-29 15:23:27,389: anaconda 24.13.7-1 for Fedora-Rescate-Silicon 24
> (pre-release) started.
> 2016-09-29 15:23:27,389: The 'logging' function is not a part of DNF API
> and will be removed in the upcoming DNF release. Please use only officially
> supported API functions. DNF API documentation is available at
> https://dnf.readthedocs.org/en/latest/api.html.
> 2016-09-29 15:23:29,478: Running anaconda failed: process '['anaconda',
> '--kickstart', '/home/sergio/Descargas/Pagure/flat-fedora-live-base.ks',
> '--cmdline', '--dirinstall', '--remotelog', '127.0.0.1:46181']' exited with
> status 1
> 2016-09-29 15:23:29,478: Shutting down log processing
> 2016-09-29 15:23:29,650: Install failed: novirt_install failed
> 2016-09-29 15:23:29,652: Removing bad disk image
> 2016-09-29 15:23:29,684: ERROR: Image creation failed: novirt_install failed
>
> Am I doing something wrong?
That error means the anaconda install failed. The way livemedia_creator
works is that it actually runs an anaconda install using the kickstart
specified - using its 'install to a directory' method if you pass --no-
virt, otherwise in a VM - then creates an image file from the resulting
installation.
You'd need to look at the generated log files, probably anaconda.log ,
to see what exactly went wrong.
I'd probably advise against running livemedia-creator with the --no-
virt option in your actual production environment, it could potentially
cause problems. The way I've found to make lmc fly (though it's a bit
awkward, and I need to get around to writing some scripts to make it
more convenient) is to mimic what Koji does for production builds, and
run it in a mock chroot. Basically, set up a clean mock chroot of the
release you actually want to create a live image for, install the
creation tools into the mock root with 'mock -r (whatever) --install
livemedia-creator' (and whatever other packages are needed, I forget)
then run 'mock -r (whatever) --shell' and do the live image creation
inside the shell. It's been a few weeks since I did this so I forget a
few annoying twiddly details you run into along the way, but that
basically worked for me.
I actually just steal the kickstarts from Koji - you can just grab a
kickstart from a completed official live image task, and customize it
if you want. I find that easier than trying to generate the flattened
kickstarts lmc wants...
Hope that helps a bit, anyway...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
unretire kompose package
I am trying to package [1] in fedora and there is a name conflict with an old/retired package [2] that no longer has an upstream. I have talked with the old maintainer (cc'd) and we would like to unretire the package and allow for the new project to assume the name in rpm. I'm attempting to follow the process described at [3]. I will request for the package to be unretired and file a ticket for releng to unblock the package. I have already had the new package spec file reviewed in Fedora [4]. Dusty [1] https://github.com/skippbox/kompose [2] https://admin.fedoraproject.org/pkgdb/package/rpms/kompose/ [3] https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package [4] https://bugzilla.redhat.com/show_bug.cgi?id=1379460 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Cannot build live iso using livemedia-creator
Hi,
I've tried to create a Live ISO using livemedia-creator, and followed the
steps from
https://fedoraproject.org/wiki/Livemedia-creator-_How_to_create_and_use_a_Live_CD
.
But I cannot do it, these is the errors:
sudo livemedia-creator --ks
/home/sergio/Descargas/Pagure/flat-fedora-live-base.ks --no-virt
--resultdir /home/lmc --project Fedora-Rescate-Silicon --make-iso --volid
Fedora24-Rescate-Silicon --iso-only --iso-name F24-R-R-Silicon.iso
/usr/lib64/python3.5/optparse.py:999: PendingDeprecationWarning: The
KSOption class is deprecated and will be removed in pykickstart-3. Use the
argparse module instead.
option = self.option_class(*args, **kwargs)
2016-09-29 15:23:19,900: disk_img = /home/lmc/lmc-disk-flpdk287.img
2016-09-29 15:23:19,901: Using disk size of 5122MiB
2016-09-29 15:23:22,380: Running anaconda.
2016-09-29 15:23:24,103: Processing logs from ('127.0.0.1', 51634)
2016-09-29 15:23:27,388: The 'logging' function is not a part of DNF API
and will be removed in the upcoming DNF release. Please use only officially
supported API functions. DNF API documentation is available at
https://dnf.readthedocs.org/en/latest/api.html.
2016-09-29 15:23:27,388: Starting installer, one moment...
2016-09-29 15:23:27,389: terminal size detection failed, using default width
2016-09-29 15:23:27,389: anaconda 24.13.7-1 for Fedora-Rescate-Silicon 24
(pre-release) started.
2016-09-29 15:23:27,389: The 'logging' function is not a part of DNF API
and will be removed in the upcoming DNF release. Please use only officially
supported API functions. DNF API documentation is available at
https://dnf.readthedocs.org/en/latest/api.html.
2016-09-29 15:23:29,478: Running anaconda failed: process '['anaconda',
'--kickstart', '/home/sergio/Descargas/Pagure/flat-fedora-live-base.ks',
'--cmdline', '--dirinstall', '--remotelog', '127.0.0.1:46181']' exited with
status 1
2016-09-29 15:23:29,478: Shutting down log processing
2016-09-29 15:23:29,650: Install failed: novirt_install failed
2016-09-29 15:23:29,652: Removing bad disk image
2016-09-29 15:23:29,684: ERROR: Image creation failed: novirt_install failed
Am I doing something wrong?
system info:
[root@hope sergio]# uname -a ; rpm -qa | egrep 'kickstart|lorax'
Linux hope.belkin.home 4.7.3-200.fc24.x86_64 #1 SMP Wed Sep 7 17:31:21 UTC
2016 x86_64 x86_64 x86_64 GNU/Linux
lorax-templates-generic-24.20-1.fc24.x86_64
fedora-kickstarts-0.24.6-1.fc24.noarch
python3-kickstart-2.25-4.fc24.noarch
spin-kickstarts-0.24.6-1.fc24.noarch
lorax-24.20-1.fc24.x86_64
pykickstart-2.25-4.fc24.noarch
custom-kickstarts-0.24.6-1.fc24.noarch
[root@hope sergio]# cat /etc/redhat-release
Fedora release 24 (Twenty Four)
Thanks in advance!
--
--
Sergio Belkin
LPIC-2 Certified - http://www.lpi.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
soname bump of Sundials libs
Hi all. I'm about to push Sundials 2.7.0 on Rawhide branch; following libraries will change their soname: *cvode* 1.0.0 --> 2.9.0 *cvodes* 2.0.0 --> 2.9.0 *arkode* 1.0.0 --> 1.1.0 *ida*2.0.0 --> 2.9.0 *idas* 2.0.0 --> 1.3.0 *kinsol* 1.0.0 --> 2.9.0 Release note from upstream: http://computation.llnl.gov/projects/sundials/release-history Packages dependent should be: $ repoquery --releasever=rawhide --all --recursive --whatrequires "libsundials_*.so.*()(64bit)" bionetgen-0:2.2.6-2.fc25.x86_64 bionetgen-perl-0:2.2.6-2.fc25.noarch python-pysb-0:1.0.1-5.fc26.noarch python-pysb-doc-0:1.0.1-5.fc26.noarch python2-assimulo-0:2.9-3.fc26.x86_64 python3-assimulo-0:2.9-3.fc26.x86_64 -- --- Antonio Trande mailto: sagitter 'at' fedoraproject 'dot' org http://fedoraos.wordpress.com/ https://fedoraproject.org/wiki/User:Sagitter GPG Key: 0x6CE6D08A Check on https://keys.fedoraproject.org/ signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Reminder: Please test F23 kernels
(cross post from kernel) We're starting to see a fall off in F23 karma. The kernel gets new releases fairly frequently so this may start to slow down how fast F23 gets new kernels. If you still have an F23 system, please remember to test and give karma for new kernels. A big thanks to those who have been regularly testing older releases. Thanks, Laura ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora 25-20160929.n.0 compose check report
On Thu, 2016-09-29 at 16:21 +, Fedora compose checker wrote: > Missing expected images: > > Cloud_base raw-xz i386 > > Failed openQA tests: 3/102 (x86_64), 1/17 (i386) > > New failures (same test did not fail in 25-20160928.n.0): > > ID: 37156 Test: x86_64 Workstation-live-iso desktop_update_graphical > URL: https://openqa.fedoraproject.org/tests/37156 Test waited ten minutes for updates to refresh, they didn't. A packagekit crash was logged and shows up as: https://bugzilla.redhat.com/show_bug.cgi?id=1378167 -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F26 System Wide Change: OpenSSL 1.1.0
Tomas Mraz wrote: > My personal recommendation would be to follow the application's upstream > recommendation. This is of course the best approach, as the upstream project will have good reasons to use a particular crypto foundation for the project. > What we should strive for is to limit the use of crypto to one of these > three libraries and avoid any additional ones with exception of > libgcrypt for gnupg2. This assumption ignores the fact that Cryptlib has joined Fedora and has every right to be included in that list. https://admin.fedoraproject.org/pkgdb/package/rpms/cryptlib/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Rawhide-20160929.n.0 compose check report
On Thu, 2016-09-29 at 16:23 +, Fedora compose checker wrote: > Missing expected images: > > Cloud_base raw-xz i386 > Atomic raw-xz x86_64 > > Failed openQA tests: 9/102 (x86_64), 2/17 (i386), 1/2 (arm) > > New failures (same test did not fail in Rawhide-20160928.n.0): > > ID: 37036 Test: x86_64 Workstation-boot-iso install_default > URL: https://openqa.fedoraproject.org/tests/37036 > ID: 37037 Test: x86_64 Workstation-boot-iso install_default@uefi > URL: https://openqa.fedoraproject.org/tests/37037 > ID: 37039 Test: i386 Workstation-boot-iso install_default > URL: https://openqa.fedoraproject.org/tests/37039 These all fail because of the stuff I've been explaining on devel@ in the last day or so: the netinst default-install tests still run with default repository configuration (as that's kind of the point), so the package metadata they got was for the *previous* compose - 20160928.n.0 - which had a dependency issue that prevented the Workstation package set from being installable. (This is why 20160928.n.0 was missing its Workstation live images). > ID: 37049 Test: x86_64 KDE-live-iso desktop_browser > URL: https://openqa.fedoraproject.org/tests/37049 Odd one, the 'install plugin' popover just mysteriously disappeared. I re-ran the test. > ID: 37054 Test: arm Minimal-raw_xz-raw.xz base_services_start_arm > URL: https://openqa.fedoraproject.org/tests/37054 Test issue; the current 'log in to the console' implementation doesn't wait long enough, basically (it's right on the edge, sometimes this test fails, sometimes it passes, with the current code). I have a revised implementation under review. > ID: 37069 Test: x86_64 Server-dvd-iso server_cockpit_basic > URL: https://openqa.fedoraproject.org/tests/37069 Hum, probably a test issue again, I think it somehow managed to click right when the UI was being changed somehow. A re-run passed. Might have to tweak the test's wait times or something. > ID: 37103 Test: x86_64 universal install_simple_free_space@uefi > URL: https://openqa.fedoraproject.org/tests/37103 This one hit that LVM timeout bug openQA installs seem to run into occasionally: https://bugzilla.redhat.com/show_bug.cgi?id=1378970 > ID: 37119 Test: x86_64 universal upgrade_2_desktop_64bit > URL: https://openqa.fedoraproject.org/tests/37119 This one hit the gnome-shell SIGTRAP crash that's been popping up here and there lately, https://bugzilla.redhat.com/show_bug.cgi?id=1370073 -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Rawhide-20160929.n.0 compose check report
Missing expected images: Cloud_base raw-xz i386 Atomic raw-xz x86_64 Failed openQA tests: 9/102 (x86_64), 2/17 (i386), 1/2 (arm) New failures (same test did not fail in Rawhide-20160928.n.0): ID: 37036 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/37036 ID: 37037 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/37037 ID: 37039 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/37039 ID: 37049 Test: x86_64 KDE-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/37049 ID: 37054 Test: arm Minimal-raw_xz-raw.xz base_services_start_arm URL: https://openqa.fedoraproject.org/tests/37054 ID: 37069 Test: x86_64 Server-dvd-iso server_cockpit_basic URL: https://openqa.fedoraproject.org/tests/37069 ID: 37103 Test: x86_64 universal install_simple_free_space@uefi URL: https://openqa.fedoraproject.org/tests/37103 ID: 37119 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/37119 Old failures (same test failed in Rawhide-20160928.n.0): ID: 37040 Test: x86_64 Atomic-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/37040 ID: 37100 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/37100 ID: 37131 Test: x86_64 universal install_rescue_encrypted URL: https://openqa.fedoraproject.org/tests/37131 ID: 37141 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/37141 Soft failed openQA tests: 1/102 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test did not softfail in Rawhide-20160928.n.0): ID: 37041 Test: x86_64 KDE-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/37041 Passed openQA tests: 92/102 (x86_64), 15/17 (i386), 1/2 (arm) New passes (same test did not pass in Rawhide-20160928.n.0): ID: 37025 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/37025 ID: 37026 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/37026 ID: 37027 Test: x86_64 Workstation-live-iso base_selinux URL: https://openqa.fedoraproject.org/tests/37027 ID: 37028 Test: x86_64 Workstation-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/37028 ID: 37029 Test: x86_64 Workstation-live-iso base_service_manipulation URL: https://openqa.fedoraproject.org/tests/37029 ID: 37030 Test: x86_64 Workstation-live-iso base_update_cli URL: https://openqa.fedoraproject.org/tests/37030 ID: 37031 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/37031 ID: 37032 Test: x86_64 Workstation-live-iso desktop_terminal URL: https://openqa.fedoraproject.org/tests/37032 ID: 37033 Test: x86_64 Workstation-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/37033 ID: 37034 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/37034 ID: 37035 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/37035 ID: 37038 Test: i386 Workstation-live-iso install_default URL: https://openqa.fedoraproject.org/tests/37038 ID: 37047 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/37047 ID: 37053 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/37053 -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 25-20160929.n.0 compose check report
Missing expected images: Cloud_base raw-xz i386 Failed openQA tests: 3/102 (x86_64), 1/17 (i386) New failures (same test did not fail in 25-20160928.n.0): ID: 37156 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/37156 Old failures (same test failed in 25-20160928.n.0): ID: 37165 Test: x86_64 Atomic-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/37165 ID: 37225 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/37225 ID: 37266 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/37266 Passed openQA tests: 99/102 (x86_64), 16/17 (i386), 2/2 (arm) New passes (same test did not pass in 25-20160928.n.0): ID: 37178 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/37178 ID: 37179 Test: arm Minimal-raw_xz-raw.xz base_services_start_arm URL: https://openqa.fedoraproject.org/tests/37179 ID: 37210 Test: x86_64 universal install_delete_pata@uefi URL: https://openqa.fedoraproject.org/tests/37210 -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
devel@lists.fedoraproject.org
On Thu, Sep 29, 2016 at 11:17:51AM -0400, Stephen Gallagher wrote: > Also membership on a WG isn't required for taking action; anyone who has +1 to this point. > they see fit. The WG exists mainly as an advisory body like FESCo: > it's really there mostly to set general direction and resolve > disputes. And to make it obvious who to come to if there is a problem. > Frankly, if someone comes and does a whole bunch of work for the > Server SIG, there's a high probability that they will eventually be > offered a seat on the WG as well. It's *intended* that the chairs be > held by people doing active work, so people semi-regularly decide to > give up their seat to others. More +1. > That being said, I'd kind of like to get to a point where Project FAO is > basically just a tool container running atop a Fedora Server os-tree image. That *definitely* argues for the merge — at least eventually. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
devel@lists.fedoraproject.org
On 09/27/2016 07:11 PM, Chris Murphy wrote: > Hi, > > I was asked to start this in today's Server meeting. The genesis for > me was, I have more questions than answers and I'm fairly convinced > I'm not the only person who's kinda shrugging not knowing what all the > questions even are. Answers are important too, but good questions to > properly explore scope and liabilities have to come first. > Agreed, thanks. > Cloud WG folks had decided a while ago to focus on Atomic Host, and > sounds like now they only want to do that, and form a new Atomic WG. > [1][2] > > I see 8 base images for Cloud that aren't rpm-ostree based. Are they > in need of a new home? As best I can tell, "yes". Who's using them? No idea Are they all needed? Does it > make sense for Server WG to produce the non-Atomic Cloud deliverable > images? > So, my thoughts here is that we essentially retire *all* of them and then let the Server WG decide to resurrect one or more of them that fits with their mission. I think it's better to start from zero and add back in the ones that we want rather than to analyze what we have and try to decide which ones to abandon. > At the last Cloud meeting, it was floated whether some Cloud people > should move over to Server, or vice versa. Should there be an > Atomic/Container WG? i.e. a fourth product deliverable? > I don't think we need another WG for this. The space is already a bit crowded. Also membership on a WG isn't required for taking action; anyone who has experience generating these images that wants to keep doing so is highly encouraged to join the ser...@lists.fedoraproject.org mailing list, come to the Server SIG meetings and participate in whatever way they see fit. The WG exists mainly as an advisory body like FESCo: it's really there mostly to set general direction and resolve disputes. Frankly, if someone comes and does a whole bunch of work for the Server SIG, there's a high probability that they will eventually be offered a seat on the WG as well. It's *intended* that the chairs be held by people doing active work, so people semi-regularly decide to give up their seat to others. > Being contrary, I wondered about consolidation as a solution rather > than adding another WG and product. [3] Does anyone see Cloud WG, or > Server WG as spread too thinly? What estimate do you have for overlap > in work between Cloud and Server? Is there an economy of scale by > combining them? And is it both useful and practical to have subgroups > within a WG, to split out the sub variants of Server: hardware, cloud, > atomic host? > I don't know that we need the overhead of additional official *groups*. I think we can probably keep it all to just the Server SIG for now and work as a team. > Server and Workstation WGs have expressed interest in moving to > rpm-ostree based deployments also. So I'm confused by what an Atomic > WG would produce that's unique. Last I heard, they weren't trying to be an "Atomic WG", but rather build a complete container management solution atop OpenShift: https://fedoraproject.org/wiki/Objectives/ProjectFAO That being said, I'd kind of like to get to a point where Project FAO is basically just a tool container running atop a Fedora Server os-tree image. There are huge differences between > conventional and rpm-ostree deployments. Does it make sense for an > Atomic WG to have no outputs? And instead is liason with Server and > Workstation WGs, QA, Docs, releng, and others, to help in the > transition to this new way of delivering and maintaining Fedora? > See above, but I think that's where I'd like us to be in a couple years, but I think convergence will take some time. > It might be that the Cloud and Server PRD refreshes help sort some of > this stuff out too. > Yes, I was hoping that some of this would fall out from the Server PRD process as a natural by-product. > OK I have more questions but this is long enough. I'm certain others > can ask better questions, or versions of these ones, and in particular > the questions I haven't asked. > Thank you very much for getting this conversation started, Chris. I think it's very important to try to get everyone talking and eventually on the same page. > > [1] > https://meetbot.fedoraproject.org/fedora-meeting-1/2016-09-21/fedora_cloud_wg.2016-09-21-17.00.log.html > > > [2] > https://fedorahosted.org/cloud/ticket/170 > > [3] > (Combining) Cloud Atomic Server WGs > https://lists.fedoraproject.org/archives/list/cl...@lists.fedoraproject.org/thread/Z2P2ARN6AMMAW52F6KSOFGELQFKXHCFY/ > signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: /sbin/nologin in /etc/shells
On 29 September 2016 at 04:54, Toby Goodwin wrote: >>nologin is listed in /etc/shells since 2002 [1]. > > This seems like a extraordinary mistake, and I agree with Jonathan > Kamens' comment on the original ticket [1]. I note that his concerns > were never adequately answered; the only response was a hand-wavy "well > we did it and it doesn't seem to have broken". One of the reasons for it to be in /etc/shells was that various audit systems failed an OS if it wasn't. [Various government and bank security audit tools have rules like https://www.stigviewer.com/stig/vmware_esxi_v5/2013-01-15/finding/GEN002140-ESXI5-46 ] The second reason was that outside scripts would fail because chsh was giving an 'error' that nologin was not there. While it can be argued that these are problems with other parties what was happening is that they haven't been fixed in multiple years and everyone who had to have anything from a PCI to a .gov audit had to go put this in the file already. This basically then becomes a "do you need to manually add this on the system? [Y/N]" purchase checkmark for banks, credit card processors, government contractors. -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Bind update (CVE-2016-2776)?
On Thu, Sep 29, 2016 at 10:36 AM, Igor Gnatenko wrote: > On Thu, Sep 29, 2016 at 10:08 AM, Tomas Hozza wrote: >> On 09/29/2016 06:19 AM, Bojan Smojver wrote: >>> Could someone with sufficient access please spin up an update of bind >>> for F-24 and other flavours of Fedora. That CVE looks like a pretty >>> serious DoS. This has already been fixed in RHEL. >>> >>> Thanks, >>> >> >> Hi. >> >> I'll be pushing the updates shortly. The problem with Fedora is that we can >> not prepare the update in advance as for RHEL, because everything (git >> repos, update system, etc.) is public. > You mean before CVE has been published? Or what's the problem with being > public? In some cases, the security bugs are embargoed (so everyone has enough time to get ready for the fix) but it doesn't go very well with how our infrastructure works. Everything is public, so you can't commit, you can't build and test ahead of time to get it released when embargo is lifted. And it can take time. Some time ago OpenJDK guys contacted me as they were hit by it and I created Board ticket for hidden private builds. Board was ok with it (although it was difficult to explain embargo concept ;-) [1] but with the amount of changes needed in the infrastructure... [1] http://fedoraproject.org/wiki/Meeting:Board_meeting_2012-10-03#.23144:_Hidden_Private_Builds R. >> >> Regards, >> Tomas >> -- >> Tomas Hozza >> Associate Manager, Software Engineering - EMEA ENG Mainstream RHEL >> >> PGP: 1D9F3C2D >> UTC+2 (CEST) >> Red Hat Inc. http://cz.redhat.com >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > > > -- > -Igor Gnatenko > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Jaroslav Řezník Engineering Program Manager Office: +420 532 294 645 Mobile: +420 602 797 774 PIN: REZZABBM Red Hat, Inc. http://www.redhat.com/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Bind update (CVE-2016-2776)?
On 29 September 2016 6:08:13 PM AEST, Tomas Hozza wrote: >I'll be pushing the updates shortly. Cool, thanks. -- Bojan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Bind update (CVE-2016-2776)?
On 09/29/2016 10:36 AM, Igor Gnatenko wrote: > On Thu, Sep 29, 2016 at 10:08 AM, Tomas Hozza wrote: > > On 09/29/2016 06:19 AM, Bojan Smojver wrote: > >> Could someone with sufficient access please spin up an update of bind > >> for F-24 and other flavours of Fedora. That CVE looks like a pretty > >> serious DoS. This has already been fixed in RHEL. > >> > >> Thanks, > >> > > > > Hi. > > > > I'll be pushing the updates shortly. The problem with Fedora is that we can > > not prepare the update in advance as for RHEL, because everything (git > > repos, update system, etc.) is public. > You mean before CVE has been published? Or what's the problem with being > public? Yes, that's what I meant. Tomas > > > > Regards, > > Tomas > > -- > > Tomas Hozza > > Associate Manager, Software Engineering - EMEA ENG Mainstream RHEL > > > > PGP: 1D9F3C2D > > UTC+2 (CEST) > > Red Hat Inc. http://cz.redhat.com > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > > -- Tomas Hozza Associate Manager, Software Engineering - EMEA ENG Mainstream RHEL PGP: 1D9F3C2D UTC+2 (CEST) Red Hat Inc. http://cz.redhat.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: /sbin/nologin in /etc/shells
>nologin is listed in /etc/shells since 2002 [1]. This seems like a extraordinary mistake, and I agree with Jonathan Kamens' comment on the original ticket [1]. I note that his concerns were never adequately answered; the only response was a hand-wavy "well we did it and it doesn't seem to have broken". As an administrator, I would expect setting a user's shell to nologin to prevent all access to the system. As an example of where this expectation fails if nologin is listed in /etc/shells: vsftpd allows access to a "nologin" user (it uses pam_shells). I've read and re-read the original RFE [2]. The argument advanced for the change is "so that 'chsh' and other tools will allow its use without manual edit of /etc/passwd". I have no idea if that was true of chsh in RedHat 7.3, but in Fedora 24 chsh allows root to set any shell at all, with a warning if it doesn't exist, or isn't in /etc/shells. With nologin absent from /etc/shells, non-root users are prevented from using chsh to change their own shell to nologin, but this seems like a feature not a bug. I can imagine in my student days "chsh -s /sbin/nologin; clear" would have seemed like the ideal prank to type into an unattended terminal! Can anyone name the "other tools" that R P Herrold might have had in mind? I've found system-config-users which only allows setting a shell listed in /etc/shells. One remedy would be for system-config-users to follow the lead of chsh, and allow any shell to be set with a warning. [1] https://bugzilla.redhat.com/show_bug.cgi?id=53963#c6 [2] https://bugzilla.redhat.com/show_bug.cgi?id=53963#c0 Toby. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
ppisar pushed to perl-Test2-Suite (f25). "0.000060 bump"
From 958e51e734086d8a8caeec6cf19c2da998f57bf1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?=
Date: Thu, 29 Sep 2016 10:52:05 +0200
Subject: 0.60 bump
---
.gitignore| 1 +
perl-Test2-Suite.spec | 5 -
sources | 2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/.gitignore b/.gitignore
index 49002d4..f1e1c8b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -18,3 +18,4 @@
/Test2-Suite-0.54.tar.gz
/Test2-Suite-0.55.tar.gz
/Test2-Suite-0.58.tar.gz
+/Test2-Suite-0.60.tar.gz
diff --git a/perl-Test2-Suite.spec b/perl-Test2-Suite.spec
index dbd45b1..6c5 100644
--- a/perl-Test2-Suite.spec
+++ b/perl-Test2-Suite.spec
@@ -1,5 +1,5 @@
Name: perl-Test2-Suite
-Version:0.58
+Version:0.60
Release:1%{?dist}
Summary:Set of tools built upon the Test2 framework
License:GPL+ or Artistic
@@ -77,6 +77,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu Sep 29 2016 Petr Pisar - 0.60-1
+- 0.60 bump
+
* Fri Sep 02 2016 Petr Pisar - 0.58-1
- 0.58 bump
diff --git a/sources b/sources
index eaa3314..f80e15d 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-e8afb4130ab0a175c1e1f5529db87bfc Test2-Suite-0.58.tar.gz
+6cb3de0e465300f771c8e0d2b77754d5 Test2-Suite-0.60.tar.gz
--
cgit v0.12
http://pkgs.fedoraproject.org/cgit/perl-Test2-Suite.git/commit/?h=f25&id=958e51e734086d8a8caeec6cf19c2da998f57bf1
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Re: F26 System Wide Change: OpenSSL 1.1.0
On 29 Sep 2016, at 08:51, Nikos Mavrogiannopoulos wrote: > I'd like to underline the part _preferrably the version recommended by > upstream_ of Packaging:CryptoPolicies. I believe it is best for us to > use the code that upstream primarily considers best for the > application. +1. Regards, Graham -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Bind update (CVE-2016-2776)?
On Thu, Sep 29, 2016 at 10:08 AM, Tomas Hozza wrote: > On 09/29/2016 06:19 AM, Bojan Smojver wrote: >> Could someone with sufficient access please spin up an update of bind >> for F-24 and other flavours of Fedora. That CVE looks like a pretty >> serious DoS. This has already been fixed in RHEL. >> >> Thanks, >> > > Hi. > > I'll be pushing the updates shortly. The problem with Fedora is that we can > not prepare the update in advance as for RHEL, because everything (git repos, > update system, etc.) is public. You mean before CVE has been published? Or what's the problem with being public? > > Regards, > Tomas > -- > Tomas Hozza > Associate Manager, Software Engineering - EMEA ENG Mainstream RHEL > > PGP: 1D9F3C2D > UTC+2 (CEST) > Red Hat Inc. http://cz.redhat.com > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Bind update (CVE-2016-2776)?
On 09/29/2016 06:19 AM, Bojan Smojver wrote: > Could someone with sufficient access please spin up an update of bind > for F-24 and other flavours of Fedora. That CVE looks like a pretty > serious DoS. This has already been fixed in RHEL. > > Thanks, > Hi. I'll be pushing the updates shortly. The problem with Fedora is that we can not prepare the update in advance as for RHEL, because everything (git repos, update system, etc.) is public. Regards, Tomas -- Tomas Hozza Associate Manager, Software Engineering - EMEA ENG Mainstream RHEL PGP: 1D9F3C2D UTC+2 (CEST) Red Hat Inc. http://cz.redhat.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F26 System Wide Change: OpenSSL 1.1.0
On Wed, 2016-09-28 at 11:43 -0400, Matthew Miller wrote: > On Wed, Sep 28, 2016 at 03:13:34PM +0100, Tomasz Kłoczko wrote: > > > > Is it any official Fedora policy/call to move away from openssl? > > As far as I know, no. There was this attempt: > https://fedoraproject.org/wiki/FedoraCryptoConsolidation > but as the top of the page notes, the effort has been abandoned. > (It's > basically impossible to change every project in the world.) From that > document, though: > > The libraries that should be preferred instead of arbitrary other > crypto stacks are (in the order of the preference): > > 1. NSS > 2. GNUTLS (with nettle as crypto backend, but nettle never used > directly by applications) > 3. OpenSSL > 4. libgcrypt > and it might be reasonable to keep this as a "if possible, please > prefer" policy rather than a mandate. I'd like to underline the part _preferrably the version recommended by upstream_ of Packaging:CryptoPolicies. I believe it is best for us to use the code that upstream primarily considers best for the application. regards, Nikos ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F26 System Wide Change: OpenSSL 1.1.0
On 28.9.2016 16:13, Tomasz Kłoczko wrote:
BTW openssl changes.
Is it any official Fedora policy/call to move away from openssl?
I'm asking because I've noticed that some packages seems have been
switched from openssl to gnutls.
Examples of those packages is wget:
* Tue Jul 26 2016 Tomas Hozza mailto:tho...@redhat.com>> - 1.18-2
- Switched openssl to gnutls for crypto
Another package example which is is linked with gntls instead with
openssl is lftp.
A the moment in Fedora is possible to use three types of SSL/crypto
libraries: gnutls, openssl and nss.
Short test on my system:
$ for i in nss gnutls openssl-libs; do echo -n "$i "; rpm -e $i 2>&1 |
awk '{print $6}' | grep -v ^$i | sort | uniq | wc -l; done
nss 57
gnutls 33
openssl-libs 110
I do not think we are going to drop any of these three tls/crypto
libraries from Fedora (and RHEL) in foreseeable future. So there is no
point in forcibly switching applications to particular one.
My personal recommendation would be to follow the application's upstream
recommendation.
What we should strive for is to limit the use of crypto to one of these
three libraries and avoid any additional ones with exception of
libgcrypt for gnupg2.
Tomas Mraz
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
