similar to: Another Fedora decision

On Wed, February 4, 2015 16:55, Warren Young wrote: >> On Feb 4, 2015, at 12:16 PM, Lamar Owen <lowen at pari.edu> wrote: >> >> Again, the real bruteforce danger is when your /etc/shadow is >> exfiltrated by a security vulnerability > > Unless you have misconfigured your system, anyone who can copy > /etc/shadow already has root privileges. They do not need

On 02/03/2015 03:44 PM, Always Learning wrote: > There should be a basic defence that when the password is wrong 'n' > occasions the IP address is blocked automatically and permanently > unless it is specifically allowed in IP Tables. As has been mentioned, fail2ban does this. However, the reason you want a password that is not easily bruteforced has nothing to do with this,

> On Feb 4, 2015, at 12:16 PM, Lamar Owen <lowen at pari.edu> wrote: > > Again, the real bruteforce danger is when your /etc/shadow is exfiltrated by a security vulnerability Unless you have misconfigured your system, anyone who can copy /etc/shadow already has root privileges. They don?t need to crack your passwords now. You?re already boned.

On Thu, February 5, 2015 9:06 am, James B. Byrne wrote: > > On Wed, February 4, 2015 16:55, Warren Young wrote: >>> On Feb 4, 2015, at 12:16 PM, Lamar Owen <lowen at pari.edu> wrote: >>> >>> Again, the real bruteforce danger is when your /etc/shadow is >>> exfiltrated by a security vulnerability >> >> Unless you have misconfigured your

On Wed, 2015-02-04 at 14:55 -0700, Warren Young wrote: > > On Feb 4, 2015, at 12:16 PM, Lamar Owen <lowen at pari.edu> wrote: > > > > Again, the real bruteforce danger is when your /etc/shadow is exfiltrated by a security vulnerability > > Unless you have misconfigured your system, anyone who can copy /etc/shadow already has root privileges. They don?t need to

On 02/04/2015 04:55 PM, Warren Young wrote: > Unless you have misconfigured your system, anyone who can copy > /etc/shadow already has root privileges. They don?t need to crack your > passwords now. You?re already boned. Not exactly. There have been remotely exploitable vulnerabilities where an arbitrary file could be read (not written), but otherwise root access wasn't given

On 8/1/20 5:00 AM, Johnny Hughes wrote: > > I would wait and install everything as a group. We should have > something soon. First off, Johnny and all of the rest of the CentOS team, thank you for your efforts! Second, to all with this problem, I too experienced the issue (I posted on the CentOS-Devel list my findings).? To those who seem to think more testing could have prevented

On 07/28/2015 03:06 PM, Chris Adams wrote: > Once upon a time, Warren Young <wyml at etr-usa.com> said: >> Much of the evil on the Internet today ? DDoS armies, spam spewers, phishing botnets ? is done on pnwed hardware, much of which was compromised by previous botnets banging on weak SSH passwords. > Since most of that crap comes from Windows hosts, the security of Linux >

All, This is just a heads-up that the new C7 update kernel breaks ABI compatibility, at least as far as using the ELrepo nVidia drivers is concerned. I have posted more details to the ELrepo list; but since many folks use the Elrepo kmods I thought a heads-up would be appropriate. If you use the ELrepo nvidia kmod you will either need to hold off on the kernel update or uninstall the nvidia

Hi all, Since the vault for 7.3.1611 has been cleared out last sunday (20170207) - why is that? - I'm using git to download a "SRPM", or more accurately, its contents. However, using git has one major drawback: It is missing checksums for the files. Are there any plans to provide checksums for the files in git so I can be sure that what I download is actually not tampered with?

Hello, On Mon, 19 Dec 2016 11:04:28 -0500 Lamar Owen <lowen at pari.edu> wrote: > On 12/19/2016 08:44 AM, ken wrote: > > Last night installed the latest, firefox-45.6.0-1.el7.centos.x86_64. > Fired it up this morning and within the first hour it's crashed three > times. That comes to it being usable for about five minutes before it > crashes. > > > >

As much as I hate to be the bearer of news, I saw over 400 updates this morning on my upstream 6.1 box.... checking the upstream website, yeah, EL6.2 is out, at least for updates. I didn't see ISO's in my subscribed channel yet, though. I figured someone would notice soon enough. So before anyone goes into flame mode, think about the difficulties that have faced the CentOS developers in

You can get RHEL on Dell Precision mobile workstations. Laptops, just higher end.

Ran into a bit of a sticky wicket today. And for reasons that should be obvious it was a bit difficult to google for a solution, so I backed out the upgrade. So I'm hoping someone here has seen and fixed this already. System: CentOS 7, fully updated. After the nss updates in the past day or so, visiting https://www.google.com with Firefox results in the following error screen: Secure

On Wed, Jan 25, 2017 at 8:20 PM, Lamar Owen <lowen at pari.edu> wrote: > On 01/24/2017 11:29 PM, Sandro Bonazzola wrote: > >> Hi, >> the latest qemu-kvm-ev has been tagged for testing. >> Please give it a run and provide feedback. >> If nothing against it shows up, we'll tag it for release on Friday. >> >> Is it considered normal for the test

On Mon, 15 Mar 2021 at 16:26, Lamar Owen <lowen at pari.edu> wrote: > On 3/15/21 8:51 AM, Stephen John Smoogen wrote: > > Exactly that. Upstream Fedora and RHEL went to require dual density > around > > Fedora 18, RHEL-7 because the amount of data was too much. > Well, what's odd is that the actual upstream RHEL 7.9 DVD WILL fit on a > single-layer DVD. Just

hi, kvm-qemu-ev from virt7-kvm-common-release is now signed and available on buildlogs.centos.org for testing, the corresponding release file is available in the centos/7/extras/ location on buildlogs as well. Once we have some testing, we can push and announce via mirror.centos.org for wider adoption. Regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh

I have an application with is binary-only, does its job well, and is only available for either libc5 (!) or early early glibc2.0 (!!). It has been running on a Red Hat Linux 5.2 (NOT RHEL; RHL) server for a really long time, and it honestly does its job and it's not easily replaced by an open-source solution at the moment. So, I need to do one of the following things: 1.) Run Red Hat

I am running the propriatry NVIDIA driver 384.69 for GT 720 support. Jerry

Changing the subject line for good ... On Thu, Apr 7, 2011 at 8:58 AM, Lamar Owen <lowen at pari.edu> wrote: > On Thursday, April 07, 2011 11:23:51 AM Brunner, Brian T. wrote: >> AIUI: In previous releases, RH distributed source + patches. ?Starting >> 6.0 RH releases patched source. ?This makes backing out a patch, or >> backporting patches from future development in