Items tagged with: RedHat
Destination #Linux EP117 #ChrisWere Digital
On DL117 - Co-Host Chris Were, @MX_Linux 18.2, AV Linux, #GIMP Official 2.10.10, #OBSProject 23.1, 2nd Gen #AMD Proc, #Arm laptops heat up with #RedHat Hat, #ubuntu ZFS installs, DLC for #Borderlands, #supertuxkart plus our Tips, Tricks and Software Spotlight picks!.
https://destinationlinux.org/episode-117/ #Linux #LinuxGaming #Podcast
It's soon to become an easy reality thanks to Red Hat / Fedora!
Red Hat's Peter Robinson:
"We're going to be working with the team to bring Fedora to these Arm laptops very soon too! Had some great conversations with the crew at #BKK19 about this, initial focus on the SD850 devices like the Lenovo. Anyone want an Arm64 laptop as a daily driver?"
#Arm #laptop #ArmLinux #RedHat #Fedora #arm64 #Lenovo #PeterRobinson
Fedora GNU/Linux: Perfect OS and perfect body
(My special thanks to wonderful #Romania and (c) Nicu B.)
#gnu #linux #fedora #rhel #redhat #photo #pictures #female #nude #portret #os #lang ru #soft #tits #boobs
NetworkManager-1.16: Add support for WireGuard VPN tunnels and Wi-Fi Direct connections (Wi-Fi P2P).
============================================= NetworkManager-1.16 Overview of changes since NetworkManager-1.14 ============================================= This is a new stable release of NetworkManager. Notable changes include: * Check connectivity per address family. * Support "main.systemd-resolved" to let NetworkManager configure DNS settings in systemd-resolved without making it the main DNS plugin of NetworkManager. * Write "/var/run/NetworkManager/no-stub-resolv.conf" with original nameservers. That is useful with caching DNS plugins like "systemd-resolved" or "dnsmasq" where "/var/run/NetworkManager/resolv.conf" refers to localhost. * Change default "ipv4.dhcp-client-id" setting for the internal DHCP plugin from "duid" to "mac". This is a change in behavior on upgrade when using the internal DHCP plugin (unless the default is overwritten in "NetworkManager.conf" or specified per connection profile). * Improve handling of DHCP router options with internal DHCP plugin. For one, accept multiple routers and add a default-route to each. On D-Bus expose the original DNS and NTP servers without cleaning up local nameservers. * Allow binding a connections lifetime to the DBus client that activated it. * Add support for establishing Wi-Fi Direct connections (Wi-Fi P2P). * Add support for WireGuard VPN tunnels to NetworkManager. D-Bus API and libnm support all options. nmcli supports creating and managing WireGuard profiles, with the exception of configuring and showing peers. * Add initrd generator to be used by dracut and use it as new way of handling iBFT. * Deprecated "plugins.monitor-connection-files" setting in NetworkManager.conf. This option will have no effect in future versions. * Add AP and Ad-hoc support for iwd Wi-Fi backend. * Warn about invalid settings in "NetworkManager.conf". * Support announcing "ANDROID_METERED" DHCP option for shared mode. * Support SAE authentication as used for 802.11s Meshing and WPA3-Personal. * NetworkManager is no longer installed as D-Bus activatable service. * Mark docker bridges as unmanaged via udev rule. * Add new PolicyKit permission "org.freedesktop.NetworkManager.wifi.scan" for controlling Wi-Fi scanning.
Fedora [module & tools]
# dnf copr enable jdoss/wireguard # dnf install wireguard-dkms wireguard-tools
Red Hat Enterprise Linux / CentOS [module & tools]
# curl -Lo /etc/yum.repos.d/wireguard.repo [url=https://copr.fedorainfracloud.org/coprs/jdoss/wireguard/repo/epel-7/jdoss-wireguard-epel-7.repo]https://copr.fedorainfracloud.org/coprs/jdoss/wireguard/repo/epel-7/jdoss-wireguard-epel-7.repo[/url] # yum install epel-release # yum install wireguard-dkms wireguard-tools
WireGuard in NetworkManager
NetworkManager 1.16 got native support for WireGuard VPN tunnels (NEWS). WireGuard is a novel VPN tunnel protocol and implementation that spawned a lot of interest. Here I will not explain how WireGuard itself works. You can find very good documentation and introduction at wireguard.com.MORE at Gnome.org (config examples, settings, etc.):
- Side by Side Video
- Command-line Interface
- Key Generation
- NAT and Firewall Traversal Persistence
- Demo Server
Windscribe CLI - easy and quick install
Binaries, repositories, addons for browsers, .apk, etc.
- IKEv2 - Default connection mode, usually the fastest, but can be easily blocked.
- UDP - This mode uses OpenVPN protocol. UDP is usually the fastest protocol to run OpenVPN on, but can also be blocked quite easily.
- TCP - Use this if UDP fails to connect. Much more resilient to bad network conditions, but could be slower.
- Stealth - Encapsulates OpenVPN in a TLS tunnel via Stunnel. Only use this if all other methods fail. May be handy in China.
- Wstunnel - Encapsulates OpenVPN in a WebSocket. Only use this if all other methods fail. May also be handy in China.
In our desktop applications we use AES-256 cipher with SHA512 auth and a 4096-bit RSA key. We also support perfect forward secrecy.INSTALL
In our browser extensions we use TLS 1.2, ECDHE_RSA with P-256 key exchange and AES_128_GCM cipher.
Fedora 22 +n...
Create a free account if you don't have one already.
Download and install the repo as root
wget [url=https://repo.windscribe.com/fedora/windscribe.repo]https://repo.windscribe.com/fedora/windscribe.repo[/url] -O /etc/yum.repos.d/windscribe.repo
Update yum / dnf
yum update dnf update
yum install windscribe-cli dnf install windscribe-cli
Switch to NON-root user
Ubuntu (14.04 - 18.04)
Create a free account if you don't have one already.
Add the Windscribe signing key to apt
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-key FDC247B7
Add the repository to your sources.list, for example:
echo 'deb [url=https://repo.windscribe.com/ubuntu]https://repo.windscribe.com/ubuntu[/url] zesty main' | sudo tee /etc/apt/sources.list.d/windscribe-repo.list
echo 'deb [url=https://repo.windscribe.com/ubuntu]https://repo.windscribe.com/ubuntu[/url] xenial main' | sudo tee /etc/apt/sources.list.d/windscribe-repo.list
Run apt-get update
sudo apt-get update
sudo apt-get install windscribe-cli
The simple and the best way (binaries):
# cd /home/user/distro/windscribe # ls /home/user/distro/windscribe -rw-r--r--. 1 13K 2019-03-13 20:09 windscribe.txt -rw-rw-r--. 1 16M 2019-03-13 20:05 Windscribe2-130.apk -rw-rw-r--. 1 9,1M 2019-03-13 20:04 windscribe-cli_1.3-19_amd64.deb -rw-rw-r--. 1 6,9M 2019-03-13 20:02 windscribe-cli-1.3-19.amd64.rpm -rw-rw-r--. 1 6,1M 2019-03-13 20:03 windscribe-cli_1.3-19_i386.deb -rw-rw-r--. 1 7,0M 2019-03-13 18:30 windscribe-cli-1.3-19.i386.rpm -rw-rw-r--. 1 17M 2019-03-13 18:45 Windscribe.exe
For example, my beloved 😀 RPM-based distro:
# rpm -Uvh windscribe-cli-1.3-19.i386.rpm 1:windscribe-cli-1.3-19 ################################# [100%] Created symlink from /etc/systemd/system/windscribe to /usr/lib/systemd/system/windscribe.service. Created symlink from /etc/systemd/system/default.target.wants/windscribe.service to /usr/lib/systemd/system/windscribe.service.
$ windscribe [<options>] <command> [<args>]...
$ windscribe --help Show this message and exit.
status Check status of Windscribe and connection account Output current account details connect Connect to Windscribe disconnect Disconnect examples Show usage examples firewall View/Modify Firewall mode lanbypass View/Modify Firewall LAN bypass locations Output list of all available server locations login Login to Windscribe account logout Logout and disconnect port View/Modify default Port protocol View/Modify default Protocol proxy View/Modify Proxy Settings sendlog Send the debug log to Support speedtest Test the connection speed viewlog View the debug log
Connect to best locations:
windscribe connect best
Connect to specific location:
windscribe connect IL
Connect to previous location:
Disabled the firewall:
windscribe firewall off
Change connection protocol:
windscribe protocol TCP
$ windscribe connect Connecting to Israel Jerusalem Zion (UDP:443) Firewall Enabled Connected to Israel Jerusalem Zion Your IP changed from 100.00.00.000 to 188.8.131.52
$ windscribe status windscribe -- pid: 23511, status: running, uptime: 6m, %cpu: 0.0, %mem: 1.8 IP: 184.108.40.206 CONNECTED -- IL UDP (443)
$ windscribe account Username: YOUR_NAME Data Usage: 33.78 MB / 10 GB Plan: 10 GB Free
$ windscribe locations
#windscribe #security #privacy #www #internet #web #tcp #udp #gnu #linux #fedora #centos #redhat #ubuntu #windows #android #macos #encryption #crypto #AES-256 #vpn #openvpn #SHA-512 #RSA-4096 #firewall #proxy #hotspot
Understanding the Red Hat Enterprise Linux random number generator interface
January 30, 2019
Like other operating systems, Red Hat Enterprise Linux provides a cryptographically-secure pseudo-random number generator (CSPRNG) as part of our kernel. It is intended to be used by cryptographic back-ends and applications requiring cryptographic operations. Unfortunately, there is much mystery around the interfaces provided. While the new random(7) manual page does clarify some aspects, it does not fully address all common questions. In this post, we will make a brief overview of these interfaces, starting from their initialization to their use.MORE:
Note that, this post will not get into the internals of a CSPRNG. We will go through these interfaces, intentionally staying on the high-level, without considering internal details, and discuss their usefulness for an application or library that requires access to such a CSPRNG.
Note that these interfaces are a compromise of various schools of thought in the free software ecosystem and carry their historical mistakes for backward compatibility.
How does the kernel initialize its CSPRNG?
The kernel has an “entropy pool,” a place where unpredictable input observed by the kernel is mixed and stored. That pool serves as a seed to the internal CSPRNG, and until some threshold of estimated entropy is reached initially, it is considered uninitialized.
Let’s now see how the kernel initializes its entropy pool.
- After the kernel takes control on power-on, it starts filling its entropy pool by mixing interrupt timing and other unpredictable input.
- The kernel gives control to systemd.
- Next, systemd starts and initializes itself.
- Systemd, optionally, loads kernel modules which will improve the kernel's entropy gathering process on a virtual machine (e.g., virtio-rng).
- Systemd loads the rngd.service which will gather additional input entropy obtained via a random generator exposed by hardware (e.g., the x86 RDRAND instruction or similar) and jitter entropy1; this entropy is fed back into the kernel to initialize its entropy pool, typically in a matter of milliseconds.
After the last step, the kernel has its entropy pool initialized, and any systemd services started can take advantage of the kernel’s random generator.
Note that the virtio-rng kernel module loading in step (3), is an optional step which improves entropy gathering in a virtual machine by using the host's random generator to initialize the guest systems in KVM. The rngd.service loading at the final step (4) is what ensures that the kernel entropy pools are initialized on every scenario, and furthermore it continues mixing additional data in the kernel pool during system runtime.
How does the kernel provide access to its CSPRNG?
The Linux kernel, as shipped with Red Hat Enterprise Linux after 7.4, provides the following interfaces for accessing the CSPRNG:
- getrandom(): A system call which provides random data from the kernel CSPRNG. It will block only when the CSPRNG is not yet initialized.
- /dev/random: a file which if read from, will output data from the kernel CSPRNG. Reading from this file is blocked until the kernel estimates that enough random events have been accumulated since the last use (many details are omitted for clarity).
- /dev/urandom: a file which if read from, will provide data from the kernel CSPRNG. Reading from /dev/urandom will never block.
- AT_RANDOM: a location in process’ memory containing 16-bytes of random data; these are accessible via getauxval() and are always available.
The recommended kernel interface for Red Hat Enterprise Linux 7 is getrandom(); in the following paragraphs we will discuss the weaknesses and strengths of each interface which will make our statement above apparent.
This interface is described in the random(4) manpage as: “/dev/random is suitable for applications that need high-quality randomness, and can afford indeterminate delays.” The interface was designed to work even when the cryptographic primitives it depended on were broken in a catastrophic way.
In practice, because that interface depends on proven primitives like the stream cipher ChaCha20 (in the past it was SHA256), that did not prove to be a reasonable risk, and in practice its dependence on conservative randomness estimation which blocks indefinitely made it unsuitable for applications. Putting its threat model in contrast with existing applications, if the
/dev/randomthreat model applies, the majority of the protocols and algorithms that take advantage of the random generator are already untrustworthy as they depend on the same primitives.
As such, due to its unpredictable semantics, we do not recommend the use of that interface in any scenario.
The device /dev/urandom provides access to the same random generator, however it will never block, nor apply any restrictions to the amount of new random events that must be mixed in the kernel entropy pool in order to provide any output. That is quite natural given that the cryptographic primitives used by the Linux kernel random generator, when initialized, can provide enormous amounts (practically unlimited) of output prior to being considered insecure in an informational-theory sense.
Unfortunately /dev/urandom has a quite important flaw. If used early on in the boot process when the random number generator of the kernel is not fully initialized, it will still output data. The "unpredictability" or "randomness" of that data is system-specific.
That interface provides 16-bytes of randomness to each process, following the same rules and having the same limitations as /dev/urandom above, i.e., its value may be derived from an uninitialized entropy pool. Its value remains constant for the lifetime of the process, and is shared with potential children processes after fork(). It can be accessed by using the getauxval() glibc call.
Due to the limitations above, we do not recommend the use of that interface in any scenario.
The getrandom() interface provides non-blocking access to kernel CSPRNG, after the kernel's entropy pool is initialized. When the entropy pool is not initialized the function blocks, making this interface suitable not only for the typical user-space application, but also for applications requiring random data early, during the system's boot process.
Another advantage of this interface is that it does not require a file descriptor to operate. That not only simplifies code using the random generator, but also makes applications more resilient when operating in chroot() environments, because it does not require the presence of a device file.
Which CSPRNG interface should I use in my application?
How to use getrandom() in an application safely?
Don’t leave randomness to chance
#gnu #linux #redhat #rhel #fedora #centos #systemd #kernel #openssl #gnutls #nss #libgcrypt #crypto #random #urandom #security #privacy #programming #generator
I have been using #GNU and #Linux since at least tenyears, my very first distro was Ubuntu Gutsy Gibbon, I still remember the sound of the drums at my very first installation, it was amazing and it was when I fell in love with the #floss. I was even more amazed by Hardy Heron, simply perfect in every shape. I used to have a #Gnome, #Compiz and a wonderful desktop that looked like a paper comics, super cool and super exciting, fortunately ten years later I still continue to be excited for any improvements.
However, back to these days, I learned about the meaning of #BDFL, and my flirt with Ubuntu started to crumble, actually the idea of community with on top a dictator, even if benevolent, didn't sound very exiting for me, never. This is the reason why I left Ubuntu to jump in Debian.
Debian is a true community of volunteers, it is the backbone of everything is #deb based, without Debian we would not have Ubuntu, #Mint, #Elementary, etc... Even if today Ubuntu might be build totally in upstream with Snap it will never have the same manpower and talents that Debian has. In ten years the main investment of Canonical/Ubuntu has been in marketing and PR. While #RedHat invests a lot of resources in engineers stuff Ubuntu invests the majority of its effort in marketing, and it really works
In lesser than four years Ubuntu become the OS leader in the #web #sever #market, a place historically belonged to Debian:
Today Ubuntu is almost a leader in the Linux realm but is it really worth of this title?
Ubuntu stated to make a lot of improvements on itself however it reduces dramatically the amount of packages under its control and leaves the majority of them on the hands of the communities, that makes Ubuntu quite unsafe every time you grab a package outside the main repo.
I was saying Ubuntu patches and improves itself to be better than Debian, actually the latter is a collection of packages: it fixes bugs, it does the minimal and everything is almost 99% upstream. Because the premises Ubuntu must be better. Actually Ubuntu has a better installer however Debian support many more architectures, that means changing the installer to make it more friendly might be a worthless task if you are going to break something that actually works, Ubuntu has a better theme, Debian uses the one of free contributors it does not contract professionals. But is Ubuntu very much better than Debian? Is everything that Ubuntu does worthy?
If you are Debian user you do not need to read anything about it, but if you don't then apparently not!
A recent article by [b]Phoronix mainly, based on giga ethernet test, shows how Debian constantly performs better than Ubuntu (which usually ships always a newer kernel than Debian). Someone can argue that this test is not indicative because it is strictly related to the hardware in use but if you read regularly the phoronix's article **always[/b] Debian performs better than Ubuntu.
Hence if every tweaks of Ubuntu to be better than Debian is actually ineffective, I can deducted that everything is basically vaporware just a marketing trick.
Today Canonical makes a lot of money with Ubuntu, you are free to use Ubuntu but is not better than Debian, it is not lead by true community, it is sponsored by a BDFL with a clear scope since the beginning. He did a lot of mistakes (Ubuntu Phone, Unity, etc...) but eventually he got what he was looking for. But the days when Ubuntu meant I can not install Debian are finished long time ago, today Ubuntu surpassed Debian in every field but not for technical reasons.
I will never be tired to repeat it: support only true community distributions of volunteers!
En el puesto tenían a mujeres vestidas de rojo muy guapas sinceramente. Pero cuando les preguntabas estaban allí para que rellenases una encuesta y poco más.
No es que no existan mujeres que puedan hablar y responder bien ante una empresa. Pero RedHat optó por mujeres contratadas para un día que cubriesen un evento.
Para mi RedHat representa el #opensource . Y eso supone de algún modo la cara capitalista del mundillo del software libre.
Si tuviese que optar por una solución nunca metería a estos personajes en la ecuación. Pero no siempre es posible.
Por eso digo algunas veces que "al menos es GNU/Linux" con lo que trabajo. No quiere decir que sea lo que a nivel personal usase.
Ubuntu por ejemplo son como Redhat posiblemente el enemigo número 1 del software libre. Pero decirlo queda mal creo.
Check out @RedHat’s Tweet: https://twitter.com/RedHat/status/1063069413082099713?s=09