devel September 2018

devel@lists.fedoraproject.org

182 participants
260 discussions

F29 Self-Contained Change: GnuTLS enables TLS 1.3 by default
by Ben Cotton 05 Oct '18

05 Oct '18

== Summary == This change enables TLS 1.3 (draft28) support on the gnutls crypto library. == Owner == * Name: Nikos Mavrogiannopoulos == Detailed Description == This change will enable the TLS 1.3 protocol (draft28) on the gnutls library. TLS 1.3 is the latest version of the TLS protocol which addresses few shortcomings of the previous versions. The protocol has already been approved by IETF and is on its final publication stage, with only minor editorial changes expected. The change for gnutls depending is transparent to existing applications. More information for applications using gnutls: * https://nikmav.blogspot.com/2018/05/gnutls-and-tls-13.html == Benefit to Fedora == * This brings the latest TLS protocol support to applications depending on gnutls, when crypto policies are updated for TLS1.3. == Scope == * Proposal owners: * Other developers: N/A (not a System Wide Change) == Upgrade/compatibility impact == That change should have no impact on upgrade or compatibility. The TLS 1.3 protocol is designed in a way that does not cause incompatibility issues with existing (and even broken) implementations. == How To Test == * Existing work-flows which include secure communications should be tested * Command line applications which use TLS (e.g., wget, lftp), should be tested against web-sites using TLS 1.3 (e.g., www.google.com) == User Experience == That change should not be noticeable by users except for applications which report the connected protocol. Other things users will notice - Latency on TLS sessions will be reduced - Performance of establishment of TLS sessions will be improved due to ed25519/x25519 support - Privacy of TLS sessions will be improved from the perspective of passive eavesdroppers; no client certificate will be sent in the clear - Transparent rekey of long-running sessions == Dependencies == GNOME, samba, rsyslog, wget, lftp, ... == Contingency Plan == If the expected transparent addition of TLS 1.3 cannot be assured (e.g., important issues are reported), the enablement of TLS1.3 protocol will be postponed for the next fedora release. * Contingency mechanism: The gnutls maintainer will not enable TLS1.3 by default in the build * Contingency deadline: Fedora 29 beta * Blocks release? No; the contingency plan is sufficient and can avoid a release block == Documentation == * https://nikmav.blogspot.com/2018/05/gnutls-and-tls-13.html * https://www.gnutls.org/manual/gnutls.html#Upgrading-from-previous-versions -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis

6 18

Python3 will be in next major RHEL release, please adjust %if statements accordingly
by Troy Dawson 04 Oct '18

04 Oct '18

Hello, Python3 will be in the next major RHEL release. I don't mean RHEL 7.6, but with numbers higher than 7. There are many, many packages with something like the following if 0%{?fedora} %define with_python3 1 %endif If you have something like that, please change it to something like this. if 0%{?fedora} || 0%{?rhel} > 7 %define with_python3 1 %endif Thank You

21 40

Fedora for Web Development fail
by Máirín Duffy 02 Oct '18

02 Oct '18

Hi fedora-devel, This morning I set out to set up a VM for web development for a project I've been working on so I could access my development environment from multiple locations / workstations without having to set it up again and again on different systems. I had a surprisingly difficult time in doing this. The steps I followed, wanting to interact with the VM via virt-manager [1]: - Look at Atomic website page, find link for cloud images, try image advertised as libvirt (was a box image), try to import into virt-manager, fail (not a bootable image) - Realize that was a dumb move and try again with raw image. Tried to import into virt-manager, didn't know I have to decompress manually first. Fail. (not a bootable image) - Give up on Fedora base cloud image, try server. 3GB download, takes 30 min to install. Install concludes with somehow either crashing the hypervisor or disconnecting virt-manager from the hypervisor. - Realize how heavyweight server seems and it's not going to be good for something I really wanted to be lean and clean, esp when seeing stuff like snappy scroll by in the package install list (nothing against snappy, just not smtg I'd expect in a lean webdev env) - Get help in an irc development channel, learn I have to extract the raw image, hurrah, quick results except! Boot stalls. - Found out it's cloud-info stalling the boot. - Yay I have a login prompt! What's the login info? Gahhhh... - Realize have to run virt-customize --uninstall cloud-init --root-password password:whatever --selinux-relabel -a theimage - Success finally (ETA 1.5 hrs not 100% fully attended of course) Note that: - I searched the Fedora docs, website, ask Fedora, and did general searches at each point of failure and didn't find much in the way of guidance. Only in talking to a couple of knowledegable and helpful folks in real time was I able to get past the fail points. - Something else to note that's non obvious is setting up virt manager as non-root, first answer https://ask.fedoraproject.org/en/question/45805/how-to-use-virt-manager-as-… OK so my questions for you, Fedora development community: - Is running a lightweight local VM for web development a usecase we want to support? Is it dare I ask important? - If so, is what I ended up setting up what we want people in that usecase to do? (E.g. use Fedora cloud base image, set up in virt-manager or boxes, using virt-customize to remove cloud-init and configure login password? If yes to both, I would be happy to help improving docs / websites / etc. to support the use case as well as filing some RFEs in the tools to make the experience better (e.g., if virt-manager could recognize a compressed raw image and offer to decompress it or at least tell user to do so, would be a win, for example.) But if I'm doing something edge-casey or not meant to be done, obviously that's a wasted effort. Let me know what you think! Cheers, ~m [1] Note I used virt-manager bc other webdevs I know use it and I'm familiar with using it for connecting to remote hypervisors which was a main thing I wanted to do. Happy to use Boxes if it allows that since it looks so slick, don't know enough about it to know if it does!

16 37

Proposal: Add release announcement post to Go/No-Go criteria
by Ben Cotton 02 Oct '18

02 Oct '18

With today's Beta release, the release announcement post for Fedora Magazine was not ready. As a result, the announcement went out a little late and then only due to a drop-everything effort (thanks, stickster!). We have a proposal to add a fourth criterion for the Go/No-Go decision, beginning with F29 Final: 4. The release announcement post for Fedora Magazine is substantially complete As a reminder, these are the existing criteria: 1. No remaining blocker bugs 2. Release candidate compose is available 3. Test matrices for [milestone = Alpha, Beta, Final] are fully completed -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis

11 20

Orphaned python2-matplotlib
by Miro Hrončok 02 Oct '18

02 Oct '18

I've orphaned python2-matplotlib. Nobody replied to my previous heads up e-mails. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

3 7

Could not execute new_sources: Fail to upload files. Server returns status 403
by Miro Hrončok 01 Oct '18

01 Oct '18

Got this when I run `fedpkg new-sources`. $ fedpkg --release master new-sources wheel-0.32.0.tar.gz Could not execute new_sources: Fail to upload files. Server returns status 403 What do i need to do? I've rekinited, I've rerun `fedora-packager-setup`, `fedora-cert` tells me it's not needed any more. Is there something more I should do? https://status.fedoraproject.org/ is all green. Thanks, -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

2 2

Resurrection of the NeuroFedora SIG
by Ankur Sinha 01 Oct '18

01 Oct '18

Hello, https://fedoraproject.org/wiki/SIGs/NeuroFedora I've recently resurrected the NeuroFedora SIG. Many thanks to Igor and the others who'd worked on it in the past and have given us a firm base to build on. The goal --------- The (current) goal of the NeuroFedora SIG is to make Fedora an easy to use platform for neuroscientists. Neuroscience is an extremely multidisciplinary field. It brings together mathematicians, chemists, biologists, physicists, psychologists, engineers (electrical and others) computer scientists and more. A lot of software is used nowadays in Neuroscience: - data collection, analysis, and sharing - lots of image processing (a lot of ML is used here, think Data Science) - simulation of brain networks (https://neuron.yale.edu/neuron/, http://nest-simulator.org/) - dissemination of scientific results (peer reviewed and otherwise, think LaTeX) https://github.com/asoplata/open-computational-neuroscience-resources/ provides a great overview of the computational side of neuroscience. It isn't just about understanding how the brain functions, we also want to understand how it processes information---how it "computes". (Some of you will already be aware of the Human Brain Project, a flagship EU project: https://www.humanbrainproject.eu/en/) Now, given that a large proportion of neuroscientists are not trained in computer science, a lot of time and effort is spent setting up systems, installing software (often from source). This can be hard for people not well-versed in build systems and so on. So, at NeuroFedora, we will try provide a ready to use Fedora based system for neuroscientists to work with, so they can quickly get their environment set up and work on the science. Please join us! --------------- If you are interested in neuroscience, please consider joining the SIG. Packaging software is only *one* way in which one can contribute. Writing docs and answering questions about the software in NeuroFedora are other ways too, for example. You can get in touch with us here: https://fedoraproject.org/wiki/SIGs/NeuroFedora#Communication_and_getting_h… What's in it for you? --------------------- In general, it will increase your awareness of neuroscience (which is a fascinating field---but of course, I am biased). We also hope to use the Fedora classroom sessions to host beginner level classes on using the software we package. If you'd like to get into neuroscience research work, it's an excellent opportunity to learn. Fedora and Science ------------------- In general, furthering Open Science is quite in line with our goals of further FOSS---Open science shares the philosophy of FOSS. The data, the tools, the results, should be accessible to all to understand, use, learn from, and develop. I've just written to the Mindshare team asking if we can get the various Science related SIGs together and do more. You can find my e-mail here: https://lists.fedoraproject.org/archives/list/mindshare@lists.fedoraproject… Please feel free to join the discussion. -- Thanks, Regards, Ankur Sinha "FranciscoD" https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London

2 2

fedpkg clone doesn*t work
by Martin Gansser 01 Oct '18

01 Oct '18

I tried fedpkg clone lollypop Cloning into 'lollypop'... martinkg(a)pkgs.fedoraproject.org: Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Could not execute clone: Failed to execute command. [martin@f28 fedora-scm]$ fedpkg clone lollypop Cloning into 'lollypop'... Enter passphrase for key '/home/martin/.ssh/id_rsa': packet_write_wait: Connection to 209.132.181.4 port 22: Broken pipe fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Could not execute clone: Failed to execute command. [martin@f28 fedora-scm]$ ssh -vT 209.132.181.4 OpenSSH_7.8p1, OpenSSL 1.1.0h-fips 27 Mar 2018 debug1: Reading configuration data /home/martin/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: Reading configuration data /etc/ssh/ssh_config.d/05-redhat.conf debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config debug1: /etc/ssh/ssh_config.d/05-redhat.conf line 8: Applying options for * debug1: Connecting to 209.132.181.4 [209.132.181.4] port 22. debug1: Connection established. debug1: identity file /home/martin/.ssh/id_rsa type 0 debug1: identity file /home/martin/.ssh/id_rsa-cert type -1 debug1: identity file /home/martin/.ssh/id_dsa type -1 debug1: identity file /home/martin/.ssh/id_dsa-cert type -1 debug1: identity file /home/martin/.ssh/id_ecdsa type -1 debug1: identity file /home/martin/.ssh/id_ecdsa-cert type -1 debug1: identity file /home/martin/.ssh/id_ed25519 type -1 debug1: identity file /home/martin/.ssh/id_ed25519-cert type -1 debug1: identity file /home/martin/.ssh/id_xmss type -1 debug1: identity file /home/martin/.ssh/id_xmss-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_7.8 debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4 debug1: match: OpenSSH_7.4 pat OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* compat 0x04000002 debug1: Authenticating to 209.132.181.4:22 as 'martin' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: curve25519-sha256(a)libssh.org debug1: kex: host key algorithm: ssh-rsa-cert-v01(a)openssh.com debug1: kex: server->client cipher: aes256-gcm(a)openssh.com MAC: <implicit> compression: none debug1: kex: client->server cipher: aes256-gcm(a)openssh.com MAC: <implicit> compression: none debug1: kex: curve25519-sha256(a)libssh.org need=32 dh_need=32 debug1: kex: curve25519-sha256(a)libssh.org need=32 dh_need=32 debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host certificate: ssh-rsa-cert-v01(a)openssh.com SHA256:Q12OTyTeOHWlS54dTzy2BNu7wB8UKNf18+7WHIDsORc, serial 1534273416 ID "pkgs02.phx2.fedoraproject.org" CA ssh-rsa SHA256:IPuhCSNXqj4m2eq6UKYE1jHFglLgLCbBzINft+OxUMA valid from 2018-08-14T20:03:36 to 2019-08-13T21:03:36 debug1: No matching CA found. Retry with plain key debug1: Host '209.132.181.4' is known and matches the RSA host key. debug1: Found key in /home/martin/.ssh/known_hosts:3 debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512> debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Offering public key: RSA SHA256:82HdmjCwCpo/Ko2UZQVjBlOB4w+ma4vqMvXhqsE9WSU /home/martin/.ssh/id_rsa debug1: Authentications that can continue: publickey debug1: Trying private key: /home/martin/.ssh/id_dsa debug1: Trying private key: /home/martin/.ssh/id_ecdsa debug1: Trying private key: /home/martin/.ssh/id_ed25519 debug1: Trying private key: /home/martin/.ssh/id_xmss debug1: No more authentication methods to try. martin(a)209.132.181.4: Permission denied (publickey). Thanks for your help

7 13

Non-responsive maintainer: Michael Rice
by Peter Oliver 01 Oct '18

01 Oct '18

Does anyone know how to contact Michael Rice, maintainer of the package python-pyvmomi? He hasn't made any commits since the package was first released. https://bugzilla.redhat.com/show_bug.cgi?id=1493946 -- Peter Oliver

2 1

Announcement: python-asyncssh license change EPL1 to EPL2/GPLv2+
by Georg Sauthoff 30 Sep '18

30 Sep '18

Hello, fyi, with the update to the latest upstream version 1.14, the python-asyncssh package (binary subpackage: python3-asyncssh) also updated its license from 'EPL-1.0' to 'EPL-2.0 or GPLv2+' (a.k.a. as EPL-2.0 with GPLv2+ secondary license clause). See also: - Package Description: Python 3 library for asynchronous client and server-side SSH communication. It uses the Python asyncio module and implements many SSH protocol features such as the various channels, SFTP, SCP, forwarding, session multiplexing over a connection and more. - Package sources: https://src.fedoraproject.org/rpms/python-asyncssh - Upstream documented license change: https://github.com/ronf/asyncssh/issues/162 - Fedora guideline regarding announcing package license changes: https://fedoraproject.org/wiki/Licensing:Main#License_Changes Best regards Georg

1 0

← Newer
1
2
3
4
5
6
7
...
26
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel September 2018