Re: [CentOS] https and self signed

[Gordon Messmer]

On 06/16/2016 10:50 PM, Walter H. wrote:

On 16.06.2016 22:02, Gordon Messmer wrote:
Without using a metaphor, please explain exactly who you think will 
not trust these certs, because I have never met these people.

then you know now, that there exist such people ...


Well, one, but I'm hardly going to tailor my security infrastructure to 
one customer.


at least the folks where their security software (antivirus, whatever) 
tells them a problem ... 


And what security software would report a problem with these 
certificates?  (bearing in mind that ~ 30% of all TLS transactions 
involve a 90-day certificate, according to telemetry)

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Gordon Messmer]

On 06/17/2016 08:19 AM, James B. Byrne wrote:

On Thu, June 16, 2016 14:23, Valeri Galtsev wrote:

Oh, this is what he meant: Cert validity period. Though I agree
with you in general (shorter period public key is exposed smaller
chance secret key brute-force discovered),

Like many things that appear to be common-sense these assumptions have
no empirical basis.  A properly generated RSA certificate and key of
sufficient strength -- RSA k>=2048bits -- should provide protection
from brute force attacks for decades if not centuries.


Yes.  The primary concern is theft, not brute forcing.  I would imagine 
that those with the resources to brute-force keys have other ways to 
intercept traffic.



The usual way a
private key gets compromised is by theft or by tampering with its
generation.  Putting yourself on a hamster wheel of constant
certificate generation and distribution simply increases the
opportunities for key theft and tampering.


No it doesn't.  If your key/cert pair exists only on the host where it 
is used, then access to that host is required to exfiltrate the key.  If 
an attacker has ongoing access to a host, in order to acquire each key 
as it is generated, then the expiration of the keys is irrelevant with 
respect to the opportunities for theft.  The opportunities are equal for 
both cases of short certificate lives and long certificate lives.


There is, however, a difference if an attacker has only brief access.  
If you shut out an attacker who has taken your key, then a short key 
lifetime returns you to a secure state sooner than a long key lifetime.


In fact, you have the logic of the situation entirely backward.  The 
interaction between the opportunity for theft and the lifetime of the 
certificate is proportional to the remaining lifetime of the certificate 
at the time of the theft.


And remember that theft doesn't necessarily mean the attacker has login 
access.  A recent OpenSSL bug allowed an attacker to read portions of 
memory, and could be used to acquire key material.




Really, unless one has evidence of penetration and theft of
the key store, what possible benefit accrues from changing secured
device keys on a frequent basis?


You aren't always going to have evidence.  Be proactive.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Gordon Messmer]

On 06/17/2016 07:56 AM, James B. Byrne wrote:

On Thu, June 16, 2016 14:09, Gordon Messmer wrote:

I doubt that most users check the dates on SSL certificates,
unless they are familiar enough with TLS to understand that
a shorter validity period is better for security.

What evidence do you possess that supports this assertion and would
you care to share it with us?



https://letsencrypt.org/2015/11/09/why-90-days.html

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Getting hibernate to work on a new CentOS 7.2.1115 install

[Globe Trotter]

Hi,


I wanted to see if anyone had any suggestions on what I could do to get 
hibernate working.
Just as a reminder, I get:
> cat /sys/power/state:
freeze mem

> cat /sys/power/disk
[disabled]

> The first should include 'disk' and the second should say enabled or
some such. 

So, clearly this is not set correctly. How do I make these changes, if I am 
allowed to?

> Note that hibernation is probably not supported by theCentOS kernel if this 
> is on a UEFI computer with Secure Boot enabled
(it's not supported by Fedora kernels) as it's a possible vector to
defeat the point of Secure Boot.

I  do have SecureBoot disabled (the computer would not boot after installation 
otherwise) and that is when I found the hidden "flag" to disable SecureBoot.
> And yet another thing is that it's possible the initramfs isn't using
resume= which is currently a problem on
Fedora. So you might need to add this to the grub.cfg on the kernel
command line, something like resume=/dev/VG/swap or wherever it is. If
it's a /dev/sdXY, i.e. on a regular partition, then use UUID.
I know how to get it working on Fedora (modify /etc/default/grub and 
grub-instlall) or so I believe. Should I have to do the same thing on CentOS?

Thanks again!
- 
   

  
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Александр Кириллов]

for me I refuse it or in other words, when there is no OCSP response
and I don't get a CRL from the CA
 the SSL-host is blocked;


Forget it, Walter. If you feel it's more secure that way I'm not going 
to waste my time to convince you otherwise. )


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Walter H.]

On 17.06.2016 22:39, Александр Кириллов wrote:

yes and no, but faking a valid OCSP response that says good instead of
revoked is also possible ...


Could you please provide any proof for that statement? If it were true 
the whole PKI infrastructure should probably be thrown out of the 
window. ) 
question back: is the SHA2 discussion a real security impact or just 
paranoia?


so provide a proof of the following statement:

"using OCSP Stapling is as secure as not using OCSP Stapling"

just think of the "parallel universe" called real life ...

do you believe a car dealer that a used car is ok, or do you want a 
proof by third party?
(here the car dealer is the server and 3rd pardy is the OCSP server or 
CRL provided by the CA)


for me I refuse it or in other words, when there is no OCSP response and 
I don't get a CRL from the CA

 the SSL-host is blocked;


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Александр Кириллов]

yes and no, but faking a valid OCSP response that says good instead of
revoked is also possible ...


Could you please provide any proof for that statement? If it were true 
the whole PKI infrastructure should probably be thrown out of the 
window. )



the primary reason was to prevent problems for connection problems -
or whatever problems - in connection with the OCSP


Sure. I've never said privacy concerns were the main reason.


Security concerns can probably be addressed with reducing update 
interval of issuer-signed OCSP responses. For my free wosign 
certificates ii's 4 days and my understanding is that interval matches 
CRL update policy of the CA.


Per RFC2560 (see nextUpdate below):

2.4  Semantics of thisUpdate, nextUpdate and producedAt

   Responses can contain three times in them - thisUpdate, nextUpdate
   and producedAt. The semantics of these fields are:

   - thisUpdate: The time at which the status being indicated is known
 to be correct
   - nextUpdate: The time at or before which newer information will be
 available about the status of the certificate
   - producedAt: The time at which the OCSP responder signed this
 response.

   If nextUpdate is not set, the responder is indicating that newer
   revocation information is available all the time.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Walter H.]

On 17.06.2016 19:57, Александр Кириллов wrote:
Then OCSP stapling is the way to go but it could be a real PITA to 
setup for the first time and may not be supported by older browsers 
anyway.



not really, because the same server tells the client that the SSL
certificate is good, as the SSL certificate itself;
these must be independent;


Says who?
the logic; anything you do to reduce problems or to prevent problems 
connecting to SSL sites because

of slow OCSP servers or similar reduces security itself ...
Yes, the OCSP response comes from the same server but it's still 
signed by the issuer CA.
yes and no, but faking a valid OCSP response that says good instead of 
revoked is also possible ...
OCSP stapling has been developed for a number of reasons including 
user privacy concerns and I find those reasons quite convincing.
the primary reason was to prevent problems for connection problems - or 
whatever problems - in connection with the OCSP
The need to revoke an issued certificate before its expiration date is 
rare.

maybe; but Heartbleed showed us something different ...;

Yet the origial OCSP implementation gives the interested third parties 
the ability to track browsing habits of unsuspecting visitors of the 
sites which do not implement OCSP stapling. This is not to mention 
much higher traffic the CAs will have to shoulder with the 
proliferation of secure sites.


of course; if there would be only one CA, and there would be only SSL, 
this CA would know what hosts you connect in your browser, because of 
OCSP ...


but the privacy concerns in this connections is less than the tracking 
cookies where a little bit more of information is sent ...
(with OCSP they know only which IP address is verifying which 
certificate and what time)


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] yum "Requires" yum-plugin-fastestmirror; why?

[Warren Young]

In another recent thread,[1] someone was having trouble with the 
yum-plugin-fastestmirror feature, so I suggested he remove it, since it’s just 
a plugin and should therefore be optional.  He reported that it couldn’t be 
removed due to package dependencies.

I investigated further and found that this also affects CentOS 5.11 and CentOS 
7.2.  (The OP is on CentOS 6.8.)  So, I reported it as a bug upstream, and they 
claim their yum package doesn’t do that, so they’re bouncing the problem back 
downstream.

I checked, and they’re right insofar as CentOS’s current C7 yum.spec file has 
this on line 118:

  Requires: yum-plugin-fastestmirror 

I then tried to go get the RHEL SRPM for yum to compare its spec file to C7’s, 
but their download site just refers visitors to git.centos.org, and the yum 
repo there doesn’t seem to have an upstream RHEL7 branch.

So, I started poking around in the yum.spec file history, and indeed, the 
oldest yum.spec file on the c7 branch doesn’t have that Requires line!  It was 
introduced in checkin f1c1b982, which claims all it does is “debrand 
yum-3.4.3-132.el7”.[2]

I realize it is in the CentOS project’s best interest if users always use the 
fastest mirror when downloading, but I claim that it is a bug to mark any 
plugin as Requires, particularly when upstream does not.
  

[1]: https://lists.centos.org/pipermail/centos/2016-June/159933.html
[2]: 
https://git.centos.org/blobdiff/rpms!yum/f1c1b9820b3d295cf5b44fa7fc8ff3673ec6d391/SPECS!yum.spec
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Александр Кириллов]

Then OCSP stapling is the way to go but it could be a real PITA to 
setup for the first time and may not be supported by older browsers 
anyway.



not really, because the same server tells the client that the SSL
certificate is good, as the SSL certificate itself;
these must be independent;


Says who? Yes, the OCSP response comes from the same server but it's 
still signed by the issuer CA. OCSP stapling has been developed for a 
number of reasons including user privacy concerns and I find those 
reasons quite convincing. The need to revoke an issued certificate 
before its expiration date is rare. CA error, transfer of the domain 
ownership, loss of a private key... What else? Yet the origial OCSP 
implementation gives the interested third parties the ability to track 
browsing habits of unsuspecting visitors of the sites which do not 
implement OCSP stapling. This is not to mention much higher traffic the 
CAs will have to shoulder with the proliferation of secure sites.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [Fwd: Re: https and self signed]

[Valeri Galtsev]

On Fri, June 17, 2016 11:50 am, James B. Byrne wrote:
>
> On Fri, June 17, 2016 12:31, Valeri Galtsev wrote:
>>
>> On Fri, June 17, 2016 10:19 am, James B. Byrne wrote:
>>
>>> Keys issued to individuals certainly should have short time limits
>>> on them.  In the same way that user accounts on systems should
>>> always have a near term expiry date set.  People are careless.
>>> And their motivations are subject to change.
>>
>> James, though in general one is likely to agree with this, I still
>> consider the conclusion I came to after discussions more than decade
>> ago valid for myself. Namely: forcing everyone to change password
>> often pisses careful people off for nothing. Passwords they create
>> and carefully keep can stand for decades, and only can be
>> compromised on some compromised machine.
>
> But I never mentioned anything about passwords.  I quite agree with
> you with respect to avoiding needless password churn.  What I wrote
> was specifically user accounts and their expiry dates.  These should
> be short. Say six to twelve months or so.  When the account expires
> then it can be renewed for another six or 12 months.  The password for
> it is not changed.

We do not expire accounts until the person leaves the Department and grace
period passes. Then we do lock account and after some time person's files
are being deleted. This is the policy, and this is what we do. The only
time when account expiration is being set is for undergraduate students
who temporarily work with some professor. For them expiration is being
changed when the continue to work with the professor next academic year.

Is this not what everybody does?

Valeri

>
> One can always write a script to automatically search for and report
> pending expirations.  There is no real need for accounts to actually
> expire.  But, even if accounts do expire for active users then it is
> not much of a hardship to report the fact and to have them
> reactivated.  On the other hand, disused accounts never get reported
> and remain deactivated.
>
> Also, when a person leaves our employ and somehow the cancellation of
> all or some their accounts gets overlooked in the out-processing then
> shortly their accounts will be deactivated automatically. A fail safe
> mechanism.
>
> --
> ***  e-Mail is NOT a SECURE channel  ***
> Do NOT transmit sensitive data via e-Mail
>  Do NOT open attachments nor follow links sent by e-Mail
>
> James B. Byrnemailto:byrn...@harte-lyne.ca
> Harte & Lyne Limited  http://www.harte-lyne.ca
> 9 Brockley Drive  vox: +1 905 561 1241
> Hamilton, Ontario fax: +1 905 561 0757
> Canada  L8E 3C3
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>



Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Would centos 7 backport this libnl3 header fix

[Jonathan Billings]

On Jun 17, 2016, at 7:14 AM, Harry Mallon  wrote:
> Would CentOS7 consider adding the following patch to libnl3?

CentOS only rebuilds RHEL packages.  I suggest going to 
https://bugzilla.redhat.com/ and filing a bug against libnl3.  If it gets 
accepted, it’ll be included in CentOS.

--
Jonathan Billings 


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] [Fwd: Re: https and self signed]

[James B. Byrne]

On Fri, June 17, 2016 12:31, Valeri Galtsev wrote:
>
> On Fri, June 17, 2016 10:19 am, James B. Byrne wrote:
>
>> Keys issued to individuals certainly should have short time limits
>> on them.  In the same way that user accounts on systems should
>> always have a near term expiry date set.  People are careless.
>> And their motivations are subject to change.
>
> James, though in general one is likely to agree with this, I still
> consider the conclusion I came to after discussions more than decade
> ago valid for myself. Namely: forcing everyone to change password
> often pisses careful people off for nothing. Passwords they create
> and carefully keep can stand for decades, and only can be
> compromised on some compromised machine.

But I never mentioned anything about passwords.  I quite agree with
you with respect to avoiding needless password churn.  What I wrote
was specifically user accounts and their expiry dates.  These should
be short. Say six to twelve months or so.  When the account expires
then it can be renewed for another six or 12 months.  The password for
it is not changed.

One can always write a script to automatically search for and report
pending expirations.  There is no real need for accounts to actually
expire.  But, even if accounts do expire for active users then it is
not much of a hardship to report the fact and to have them
reactivated.  On the other hand, disused accounts never get reported
and remain deactivated.

Also, when a person leaves our employ and somehow the cancellation of
all or some their accounts gets overlooked in the out-processing then
shortly their accounts will be deactivated automatically. A fail safe
mechanism.

-- 
***  e-Mail is NOT a SECURE channel  ***
Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Valeri Galtsev]

On Fri, June 17, 2016 10:19 am, James B. Byrne wrote:
>
> On Thu, June 16, 2016 14:23, Valeri Galtsev wrote:
>>
>> On Thu, June 16, 2016 1:09 pm, Gordon Messmer wrote:
>>>
>>> I doubt that most users check the dates on SSL certificates,
>>> unless they are familiar enough with TLS to understand that
>>> a shorter validity period is better for security.
>>
>> Oh, this is what he meant: Cert validity period. Though I agree with
you in general (shorter period public key is exposed smaller chance
secret key brute-force discovered),
>
> Like many things that appear to be common-sense these assumptions have
no empirical basis.  A properly generated RSA certificate and key of
sufficient strength -- RSA k>=2048bits -- should provide protection from
brute force attacks for decades if not centuries. The usual way a
private key gets compromised is by theft or by tampering with its
generation.  Putting yourself on a hamster wheel of constant
> certificate generation and distribution simply increases the
> opportunities for key theft and tampering.
>
> Keys issued to individuals certainly should have short time limits on
them.  In the same way that user accounts on systems should always have
a near term expiry date set.  People are careless.  And their
motivations are subject to change.

James, though in general one is likely to agree with this, I still
consider the conclusion I came to after discussions more than decade ago
valid for myself. Namely: forcing everyone to change password often sets
careful people off for nothing. Passwords they create and carefully keep
can stand for decades, and only can be compromised on some compromised
machine. Now, from my (careful person) point of view, US National labs
forcing me change password every 6 Months is just confirming the fact they
imply their boxes are compromised often. As: my passwords (passphrases)
are different everywhere, and I only connect one way ever: from trusted
(maintained by me that is) machine to untrusted (maintained by someone
else that is). Never from untrusted machine elsewhere.

Now, simple argument we had: if you force person to change password often,
even worse thing will happen: person will never remember ever changing
password and the last will be written on a piece of paper stuck to the
back of the screen or similar. Yes, I know about and I do use encrypted
storage dedicated for passwords. Does everybody? Things change but people
don't (almost don't).

So, the best bet for multi-user machine is to run it under assumption that
bad guys are already inside. Occasionally you see them attempting
elevation of privileges, smash them, and make the user whose password was
stolen change that, and change all his/her passwords everywhere, banks and
other $$$ accounts first. After this sort of exercise this same person
never is the one in this same sort of trouble. Yes I had these cases, not
many during last decade and a half. I also have seen an opposite attitude
on occasion (user didn't care his password was compromised on machine I
administer), then that user had all [bad] what sysadmin can get him...


> So having a guillotine date on a
> personal certificate makes sense from an administrative standpoint. One
wants to fail safe.  But modifying certificates on sealed
> servers?.  Really, unless one has evidence of penetration and theft of
the key store, what possible benefit accrues from changing secured
device keys on a frequent basis?

My point exactly. Only I usually try to say it in so short way, that my
point fails to propagate to readers ;-(

>
> We mainly use 4096bit keys which will be secure from brute force until
the advent of Quantum computing. At which point brute force attacks will
become a pointless worry.  Not because the existing RSA
> certificates and keys will withstand those attacks but because the
encryption process itself will move onto quantum devices.  That
> development, if and when it occurs, will prove more than the code
breakers will ever be able to handle.  Of course then one must worry
about the people who build the devices.  But we all have to do that
already.  Bought any USB devices from China recently?

Well, I started to avoid Lenovo after they shipped laptop with malware
preinstalled. It took them some time after they bought laptop line from
IBM. But yes, firmware/microcode malware is something that will bite us
soon.

BTW, the secret known to two people is not a secret Who said that?

Cheers,
Valeri

>
> --
> ***  e-Mail is NOT a SECURE channel  ***
> Do NOT transmit sensitive data via e-Mail
>  Do NOT open attachments nor follow links sent by e-Mail
>
> James B. Byrnemailto:byrn...@harte-lyne.ca
> Harte & Lyne Limited  http://www.harte-lyne.ca
> 9 Brockley Drive  vox: +1 905 561 1241
> Hamilton, Ontario fax: +1 905 561 0757
> Canada  L8E 3C3
>



Valeri Galtsev
Sr System Administrator
Department of 

Re: [CentOS] https and self signed

[Valeri Galtsev]

On Fri, June 17, 2016 9:56 am, Michael H wrote:
> On 17/06/16 15:46, James B. Byrne wrote:
>> On Thu, June 16, 2016 13:53, Walter H. wrote:
>>> On 15.06.2016 16:17, Warren Young wrote:
  but it also affects the other public CAs: you can’t get a
 publicly-trusted cert for a machine without a publicly-recognized and
-visible domain name.  For that, you still need to use
 self-signed certs or certs signed by a private CA.
>>> A private CA is the same as self signed;
>> No it is not.  A private CA is as trustworthy as the organisation that
operates it.  No more and not one bit less.
>> We operate a private CA for our domain and have since 2005.  We
maintain a public CRL strictly in accordance with our CPS and have our
own OID assigned.  Our CPS and CRL together with our active, expired
and revoked certificate inventory is available online at
>> ca.harte-lyne.ca.  Our CPS states that we will only issue certificates
for our own domain and furthermore we only issue them for equipment and
personnel under our direct control.
>> In a few years DANE is going to destroy the entire market of 'TRUSTED'
root CA's  -- because really none of them are trust 'worthy' --.  And
that development is long overdue.  When we reach that point many
domains, if not most, will have their DNS forward zones providing TLSA
RRs for their domain CA certificates and signatures.  And most of those
that do this are going to be running their own private CA's simply to
maintain control of their certificates.
>> Our DNS TLSA flags tell those that verify using DANE that our private
CA is the only authority that can issue a valid certificate for
harte-lyne.ca and its sub-domains.  Compare that to the present case
wherein any 'trusted' CA can issue a certificate for any domain
whatsoever; whether they are authorised by the domain owner or not[1].
>>  So in a future with DANE it will be possible to detect when an
>> apparently 'valid' certificate is issued by a rogue CA.
>> The existing CA structure could not have been better designed for
exploitation by special interests.  It has been and continues to be so
exploited.
>> Personally I distrust every one of the preloaded root CAs shipped with
Firefox by manually removing all of their trust flags. I do the same
with any other browser I use.  I then add back in those trusts
>> essential for my browser operation as empirical evidence warrants. So I
must trust certain DigiCert certificates for GitHub and
>> DuckDuckGo, GeoTrust for Google, COMODO for Wikipedia, and so forth.
These I set the trust flags for web services only.  The rest can go
pound salt as we used to say.
>> [1]
>> https://nakedsecurity.sophos.com/2013/12/09/serious-security-google-finds-fake-but-trusted-ssl-certificates-for-its-domains-made-in-france/
>
>
> https://harte-lyne.ca/
>
> net::ERR_CERT_AUTHORITY_INVALID
>

Michael, no offense intended, but I really would suggest to do some
reading instead of quoting what web browser tells you here. James gives
excellent explanations, and all of them are extremely instructive. But one
really needs to do a bit of reading to follow them. In a nut shell: what
James described is exactly as the CA authorities operate with slight
difference: propagation of private CA trust to clients.

Again, please, do some reading on the subject and then re-read what James
posted. Please, do not take it as offense, James' write up is really
instructive, everyone of us who ever run own Certification Authority will
attest to that.

Valeri


Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247





___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Speaking of firefox updates

[m . roth]

John Hodrien wrote:
> On Fri, 17 Jun 2016, m.r...@5-cent.us wrote:
>
>> Btw, I did just update flash-plugin. Does anyone know what the issue was
>> that caused the video issues in the first release of 45, and whether
>> those issues were resolved? Also, were they occurring in C7? Unless
that's the
>> case, it's not just me, but I've got several dozen users to update, and
>> I cannot do that, if I don't know if it will break them.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1330898
>

Ah! Thanks very much.

  mark

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Speaking of firefox updates

[John Hodrien]

On Fri, 17 Jun 2016, m.r...@5-cent.us wrote:


Btw, I did just update flash-plugin. Does anyone know what the issue was
that caused the video issues in the first release of 45, and whether those
issues were resolved? Also, were they occurring in C7? Unless that's the
case, it's not just me, but I've got several dozen users to update, and I
cannot do that, if I don't know if it will break them.


https://bugzilla.redhat.com/show_bug.cgi?id=1330898

jh
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Speaking of firefox updates

[John Hodrien]

On Fri, 17 Jun 2016, m.r...@5-cent.us wrote:


Just did some looking, and I see my (C6) mplayer is current, but ffmpeg
has an available update. So, assuming I can update ffmpeg, and it works
with mplayer (I have to use that - if nothing else, to look at
surveillance videos for our secure rooms).

Let me try updating ffmpeg, and see.

Ok, further looking: ffmpeg-libs is installed, and I see no updates. From
rpm -qi, it says 27 Oct 2014, vendor rpm fusion.

Which newer version? Btw, yum info says that ffmpeg is a *broadcasting
solution, for encoding. Am I misunderstanding something?


ffmpeg 2.6.8 from nux is known to be good.  That said, latest version of
firefox annoyingly disables ffmpeg support.  What version of firefox are you
actually running?

jh
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Speaking of firefox updates

[m . roth]

John Hodrien wrote:
> On Fri, 17 Jun 2016, m.r...@5-cent.us wrote:
>
>> I haven't gone past 38, because when the 45 update came out, and
>> video...like, say, my *required* training from work, when I tried
>> to run it, it crashed firefox. Repeatedly. 100% of the time.
>>
>> Has anyone been using the current version had trouble with video, etc?
>> I'd like to update, but not if I can't do required training
>
> I would assume you've got an old version of ffmpeg installed on your
> system, *and* that you've updated to 45 but not the latest version
available.
>
> Is that the case?
>
Btw, I did just update flash-plugin. Does anyone know what the issue was
that caused the video issues in the first release of 45, and whether those
issues were resolved? Also, were they occurring in C7? Unless that's the
case, it's not just me, but I've got several dozen users to update, and I
cannot do that, if I don't know if it will break them.

  mark

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Speaking of firefox updates

[m . roth]

John Hodrien wrote:
> On Fri, 17 Jun 2016, m.r...@5-cent.us wrote:
>
>> I haven't gone past 38, because when the 45 update came out, and
>> video...like, say, my *required* training from work, when I tried to
>> run it, it crashed firefox. Repeatedly. 100% of the time.
>>
>> Has anyone been using the current version had trouble with video, etc?
>> I'd like to update, but not if I can't do required training
>
> I would assume you've got an old version of ffmpeg installed on your
> system, *and* that you've updated to 45 but not the latest version
available.
>
> Is that the case?

Just did some looking, and I see my (C6) mplayer is current, but ffmpeg
has an available update. So, assuming I can update ffmpeg, and it works
with mplayer (I have to use that - if nothing else, to look at
surveillance videos for our secure rooms).

Let me try updating ffmpeg, and see.

Ok, further looking: ffmpeg-libs is installed, and I see no updates. From
rpm -qi, it says 27 Oct 2014, vendor rpm fusion.

Which newer version? Btw, yum info says that ffmpeg is a *broadcasting
solution, for encoding. Am I misunderstanding something?

mark

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[James B. Byrne]

On Thu, June 16, 2016 14:23, Valeri Galtsev wrote:
>
> On Thu, June 16, 2016 1:09 pm, Gordon Messmer wrote:
>>
>> I doubt that most users check the dates on SSL certificates,
>> unless they are familiar enough with TLS to understand that
>> a shorter validity period is better for security.
>
> Oh, this is what he meant: Cert validity period. Though I agree
> with you in general (shorter period public key is exposed smaller
> chance secret key brute-force discovered),

Like many things that appear to be common-sense these assumptions have
no empirical basis.  A properly generated RSA certificate and key of
sufficient strength -- RSA k>=2048bits -- should provide protection
from brute force attacks for decades if not centuries. The usual way a
private key gets compromised is by theft or by tampering with its
generation.  Putting yourself on a hamster wheel of constant
certificate generation and distribution simply increases the
opportunities for key theft and tampering.

Keys issued to individuals certainly should have short time limits on
them.  In the same way that user accounts on systems should always
have a near term expiry date set.  People are careless.  And their
motivations are subject to change.  So having a guillotine date on a
personal certificate makes sense from an administrative standpoint.
One wants to fail safe.  But modifying certificates on sealed
servers?.  Really, unless one has evidence of penetration and theft of
the key store, what possible benefit accrues from changing secured
device keys on a frequent basis?

We mainly use 4096bit keys which will be secure from brute force until
the advent of Quantum computing. At which point brute force attacks
will become a pointless worry.  Not because the existing RSA
certificates and keys will withstand those attacks but because the
encryption process itself will move onto quantum devices.  That
development, if and when it occurs, will prove more than the code
breakers will ever be able to handle.  Of course then one must worry
about the people who build the devices.  But we all have to do that
already.  Bought any USB devices from China recently?

-- 
***  e-Mail is NOT a SECURE channel  ***
Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Speaking of firefox updates

[John Hodrien]

On Fri, 17 Jun 2016, m.r...@5-cent.us wrote:


I haven't gone past 38, because when the 45 update came out, and video...
like, say, my *required* training from work, when I tried to run it, it
crashed firefox. Repeatedly. 100% of the time.

Has anyone been using the current version had trouble with video, etc? I'd
like to update, but not if I can't do required training


I would assume you've got an old version of ffmpeg installed on your system,
*and* that you've updated to 45 but not the latest version available.

Is that the case?

jh
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Speaking of firefox updates

[m . roth]

I haven't gone past 38, because when the 45 update came out, and video...
like, say, my *required* training from work, when I tried to run it, it
crashed firefox. Repeatedly. 100% of the time.

Has anyone been using the current version had trouble with video, etc? I'd
like to update, but not if I can't do required training

 mark

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Walter H.]

On 17.06.2016 16:46, James B. Byrne wrote:

On Thu, June 16, 2016 13:53, Walter H. wrote:

On 15.06.2016 16:17, Warren Young wrote:

  but it also affects the other public CAs: you can’t get a
publicly-trusted cert for a machine without a publicly-recognized
and -visible domain name.  For that, you still need to use
self-signed certs or certs signed by a private CA.


A private CA is the same as self signed;


No it is not.  A private CA is as trustworthy as the organisation that
operates it.  No more and not one bit less.

We operate a private CA for our domain and have since 2005.  We
maintain a public CRL strictly in accordance with our CPS and have our
own OID assigned.

for your understanding: every root CA certificate is self signed;
any SSL certificate that was signed by a CA not delivered as built-in 
token in a browser is the same as self-signed;



___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Michael H]

On 17/06/16 15:46, James B. Byrne wrote:
> 
> On Thu, June 16, 2016 13:53, Walter H. wrote:
>> On 15.06.2016 16:17, Warren Young wrote:
>>>  but it also affects the other public CAs: you can’t get a
>>> publicly-trusted cert for a machine without a publicly-recognized
>>> and -visible domain name.  For that, you still need to use
>>> self-signed certs or certs signed by a private CA.
>>>
>> A private CA is the same as self signed;
>>
> 
> No it is not.  A private CA is as trustworthy as the organisation that
> operates it.  No more and not one bit less.
> 
> We operate a private CA for our domain and have since 2005.  We
> maintain a public CRL strictly in accordance with our CPS and have our
> own OID assigned.  Our CPS and CRL together with our active, expired
> and revoked certificate inventory is available online at
> ca.harte-lyne.ca.  Our CPS states that we will only issue certificates
> for our own domain and furthermore we only issue them for equipment
> and personnel under our direct control.
> 
> In a few years DANE is going to destroy the entire market of 'TRUSTED'
> root CA's  -- because really none of them are trust 'worthy' --.  And
> that development is long overdue.  When we reach that point many
> domains, if not most, will have their DNS forward zones providing TLSA
> RRs for their domain CA certificates and signatures.  And most of
> those that do this are going to be running their own private CA's
> simply to maintain control of their certificates.
> 
> Our DNS TLSA flags tell those that verify using DANE that our private
> CA is the only authority that can issue a valid certificate for
> harte-lyne.ca and its sub-domains.  Compare that to the present case
> wherein any 'trusted' CA can issue a certificate for any domain
> whatsoever; whether they are authorised by the domain owner or not[1].
>  So in a future with DANE it will be possible to detect when an
> apparently 'valid' certificate is issued by a rogue CA.
> 
> The existing CA structure could not have been better designed for
> exploitation by special interests.  It has been and continues to be so
> exploited.
> 
> Personally I distrust every one of the preloaded root CAs shipped with
> Firefox by manually removing all of their trust flags. I do the same
> with any other browser I use.  I then add back in those trusts
> essential for my browser operation as empirical evidence warrants.  
> So I must trust certain DigiCert certificates for GitHub and
> DuckDuckGo, GeoTrust for Google, COMODO for Wikipedia, and so forth.
> These I set the trust flags for web services only.  The rest can go
> pound salt as we used to say.
> 
> 
> [1]
> https://nakedsecurity.sophos.com/2013/12/09/serious-security-google-finds-fake-but-trusted-ssl-certificates-for-its-domains-made-in-france/
> 


https://harte-lyne.ca/

net::ERR_CERT_AUTHORITY_INVALID

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[James B. Byrne]

On Thu, June 16, 2016 13:53, Walter H. wrote:
> On 15.06.2016 16:17, Warren Young wrote:
>>  but it also affects the other public CAs: you can’t get a
>> publicly-trusted cert for a machine without a publicly-recognized
>> and -visible domain name.  For that, you still need to use
>> self-signed certs or certs signed by a private CA.
>>
> A private CA is the same as self signed;
>

No it is not.  A private CA is as trustworthy as the organisation that
operates it.  No more and not one bit less.

We operate a private CA for our domain and have since 2005.  We
maintain a public CRL strictly in accordance with our CPS and have our
own OID assigned.  Our CPS and CRL together with our active, expired
and revoked certificate inventory is available online at
ca.harte-lyne.ca.  Our CPS states that we will only issue certificates
for our own domain and furthermore we only issue them for equipment
and personnel under our direct control.

In a few years DANE is going to destroy the entire market of 'TRUSTED'
root CA's  -- because really none of them are trust 'worthy' --.  And
that development is long overdue.  When we reach that point many
domains, if not most, will have their DNS forward zones providing TLSA
RRs for their domain CA certificates and signatures.  And most of
those that do this are going to be running their own private CA's
simply to maintain control of their certificates.

Our DNS TLSA flags tell those that verify using DANE that our private
CA is the only authority that can issue a valid certificate for
harte-lyne.ca and its sub-domains.  Compare that to the present case
wherein any 'trusted' CA can issue a certificate for any domain
whatsoever; whether they are authorised by the domain owner or not[1].
 So in a future with DANE it will be possible to detect when an
apparently 'valid' certificate is issued by a rogue CA.

The existing CA structure could not have been better designed for
exploitation by special interests.  It has been and continues to be so
exploited.

Personally I distrust every one of the preloaded root CAs shipped with
Firefox by manually removing all of their trust flags. I do the same
with any other browser I use.  I then add back in those trusts
essential for my browser operation as empirical evidence warrants.  
So I must trust certain DigiCert certificates for GitHub and
DuckDuckGo, GeoTrust for Google, COMODO for Wikipedia, and so forth.
These I set the trust flags for web services only.  The rest can go
pound salt as we used to say.


[1]
https://nakedsecurity.sophos.com/2013/12/09/serious-security-google-finds-fake-but-trusted-ssl-certificates-for-its-domains-made-in-france/

-- 
***  e-Mail is NOT a SECURE channel  ***
Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Walter H.]

On 17.06.2016 16:27, Александр Кириллов wrote:

Walter H. писал 2016-06-16 22:54:

On 16.06.2016 21:42, Александр Кириллов wrote:


I don't think OCSP is critical for free certificates suitable for 
small businesses and personal sites.



this is philosophy;

I'd say when you do it then do it good, else don't do it;


Then OCSP stapling is the way to go but it could be a real PITA to 
setup for the first time and may not be supported by older browsers 
anyway.


not really, because the same server tells the client that the SSL 
certificate is good, as the SSL certificate itself;

these must be independent;

Walter
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] https and self signed

[Александр Кириллов]

Walter H. писал 2016-06-16 22:54:

On 16.06.2016 21:42, Александр Кириллов wrote:

that is right, but hink of your potential clients, because
wosign has a problem - slow OCSP, ...
because their server infrastucture is located in China, and not the
best bandwidth ...

when validity checks of the used SSL certificate very probable fail,
it is worse than not using SSL ...


I don't think OCSP is critical for free certificates suitable for 
small businesses and personal sites.



this is philosophy;

I'd say when you do it then do it good, else don't do it;


Then OCSP stapling is the way to go but it could be a real PITA to setup 
for the first time and may not be supported by older browsers anyway.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] CD/DVD Creator (nautilus) strips file execute permissions

[Calvin Webster]

This issue is documented in Red Hat Bugzilla Bug 1346427
https://bugzilla.redhat.com/show_bug.cgi?id=1346427

There is also a case opened with Red Hat Support: CASE 01652429

There are two workarounds:

1. Downgrade to:

brasero.x86_64 2.28.3-6.el6
brasero-libs.x86_642.28.3-6.el6
brasero-nautilus.x86_642.28.3-6.el6

2. Use command line utilities mkisofs and cdrecord:

mkisofs -o ISO_file_name.iso -J -r -V Disc_Label SourceFileDirectory/
cdrecord -v speed=2 dev=/dev/sr0 ISO_file_name.iso


Details:


Problem has been confirmed to be in brasero-nautilus-2.30.3-3.el6

Downgrading brasero packages to 2.28.3-6.el6 fixes the problem.

Description of problem:

After updating to RHEL 6.8, burning data optical discs using CD/DVD
Creator causes all regular file execute permissions to be removed.
Directory execute permissions are retained. This problem only appeared
after updating to RHEL/CentOS 6.8 from 6.7.

Using mkisofs / cdrecord with the same data produces optical media with
normal file permissions - all execute permissions are retained on files
and directories.

Steps to Reproduce:
1. Insert blank optical media in CD/DVD writer
2. Select [Open CD/DVD Creator] when prompted and click [OK]
3. Drag files and directories with execute permissions into the creator
window
4. Click [Write to Disc]

Actual results:

Excerpt from "ls -l":
---
[cwebster@klink InstallDisks]$ ls
-l /media/CymSTAR_Linux_Support/scripts/
total 50
-r--r--r--. 1 cwebster cwebster  457 Jun 14 14:37 cleanup_packages
-r--r--r--. 1 cwebster cwebster 6962 Jun 14 14:37 fix_eth_devs.py
-r--r--r--. 1 cwebster cwebster 1790 Jun 14 14:37 install_audioscience
...
-r--r--r--. 1 cwebster cwebster  863 Jun 14 14:37 setup_shutdownFlarbs
-r--r--r--. 1 cwebster cwebster 1692 Jun 14 14:37 setup_ssh
-r--r--r--. 1 cwebster cwebster  252 Jun 14 14:37 setup_svn
-r--r--r--. 1 cwebster cwebster  429 Jun 14 14:37 start_vsftpd
-r--r--r--. 1 cwebster cwebster  788 Jun 14 14:37 update_samba
[cwebster@klink InstallDisks]$ 

---

Expected results:

Excerpt from "ls -l":
---
[cwebster@klink InstallDisks]$ ls
-l /media/CymSTAR_Linux_Support/scripts/
total 50
-r-xr-xr-x. 1 cwebster cwebster  457 Jun  4  2015 cleanup_packages
-r-xr-xr-x. 1 cwebster cwebster 6962 Jun  4  2015 fix_eth_devs.py
-r-xr-xr-x. 1 cwebster cwebster 1790 Mar  3 15:42 install_audioscience
...
-r-xr-xr-x. 1 cwebster cwebster  863 Jun 11 12:33 setup_shutdownFlarbs
-r-xr-xr-x. 1 cwebster cwebster 1692 Jun  4  2015 setup_ssh
-r-xr-xr-x. 1 cwebster cwebster  252 Jun  4  2015 setup_svn
-r-xr-xr-x. 1 cwebster cwebster  429 Sep  3  2015 start_vsftpd
-r-xr-xr-x. 1 cwebster cwebster  788 Dec 15 14:59 update_samba
[cwebster@klink InstallDisks]$ 

---


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Error: Could not find or load main class with OpenJDK and Oracle Java

[Alexander Farber]

Nevermind, I had to move my test file under
thepackagename/TheClassName.class and then it runs fine.

However my real program [1] consisting of few jar-files still
does not run on CentOS (while running fine on Windows).

I have to investigate more and will ask a separate question.

Regards
Alex

[1]: https://github.com/afarber/jetty-newbie/tree/master/WebsocketHandler
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] CentOS-announce Digest, Vol 136, Issue 3

[centos-announce-request]

Send CentOS-announce mailing list submissions to
centos-annou...@centos.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.centos.org/mailman/listinfo/centos-announce
or, via email, send a message with subject or body 'help' to
centos-announce-requ...@centos.org

You can reach the person managing the list at
centos-announce-ow...@centos.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of CentOS-announce digest..."


Today's Topics:

   1. Updated Vagrant Box's are now available : 1605 (Karanbir Singh)
   2. CESA-2016:1217 Critical CentOS 6 firefox Security Update
  (Johnny Hughes)
   3. CESA-2016:1217 Critical CentOS 5 firefox Security Update
  (Johnny Hughes)
   4. CESA-2016:1217 Critical CentOS 7 firefox Security Update
  (Johnny Hughes)
   5. CESA-2016:1237 Important CentOS 6 ImageMagick Security Update
  (Johnny Hughes)
   6. CESA-2016:1237 Important CentOS 7 ImageMagick Security Update
  (Johnny Hughes)


--

Message: 1
Date: Thu, 16 Jun 2016 15:39:58 +0100
From: Karanbir Singh 
To: CentOS Announcements List 
Subject: [CentOS-announce] Updated Vagrant Box's are now available :
1605
Message-ID: 
Content-Type: text/plain; charset=utf-8

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Updated Vagrant box's are now available for CentOS Linux 7/x86_64 and
for the first time for CentOS Linux 6/x86_64; We are providing box's
for Livbirt provider and the Virtual Box provider.

ref: https://atlas.hashicorp.com/centos/boxes/6
 https://atlas.hashicorp.com/centos/boxes/7

Release Notes for these images are published at :

https://seven.centos.org/2016/06/updated-centos-vagrant-images-available
/

regards,

- -- 
Karanbir Singh, Project Lead, The CentOS Project
+44-207-0999389 | http://www.centos.org/ | twitter.com/CentOS
GnuPG Key : http://www.karan.org/publickey.asc
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJXYro+AAoJEI3Oi2Mx7xbtD0wH/258qtXogCXBwFDOId4d7PmV
bRVyYp+i0wX+yG6xWrziDXjWoRB/xa+YUJX39qvhP2PGikJg7aj9K+z5DS9Y9Dfp
hBMfmQ17MvIV53cfPeNnL06wSOZ+Y93awN7fr7It8nR4imAgXXouAX0YjDioOP2j
GTteuu0ieyYU87sG/CZuHBGPgvsL4u5XVba19VY+0b12pv3z9kHJeHIwReQX3WVT
7C2cstXTsnEC/BYdbfPj+hFKRZGwuAiA5JDLN53eoOuQReIfnYfU2a/ugebTUH8G
X12J64IaKDfCd6018DC+uUDtmaiFwXlxeaKyHqXO7m6EiCMQrhRty2CPNajVk08=
=wR1K
-END PGP SIGNATURE-


--

Message: 2
Date: Wed, 8 Jun 2016 23:13:32 +
From: Johnny Hughes 
To: centos-annou...@centos.org
Subject: [CentOS-announce] CESA-2016:1217 Critical CentOS 6 firefox
SecurityUpdate
Message-ID: <20160608231332.ga55...@n04.lon1.karan.org>
Content-Type: text/plain; charset=us-ascii


CentOS Errata and Security Advisory 2016:1217 Critical

Upstream details at : https://rhn.redhat.com/errata/RHSA-2016-1217.html

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

i386:
acc8466a5e2e7b4f97e476ef08608babd3957f9dea929ede45436549dd189940  
firefox-45.2.0-1.el6.centos.i686.rpm

x86_64:
acc8466a5e2e7b4f97e476ef08608babd3957f9dea929ede45436549dd189940  
firefox-45.2.0-1.el6.centos.i686.rpm
3c0badf351a25c811dce868afd434b9341a3da64018937be7bac76c39ecb5a42  
firefox-45.2.0-1.el6.centos.x86_64.rpm

Source:
733ca4db9bc0d6dcb4edc0d270299834e4b78b0f115025fd310146ce420380e2  
firefox-45.2.0-1.el6.centos.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS



--

Message: 3
Date: Wed, 8 Jun 2016 23:28:21 +
From: Johnny Hughes 
To: centos-annou...@centos.org
Subject: [CentOS-announce] CESA-2016:1217 Critical CentOS 5 firefox
SecurityUpdate
Message-ID: <20160608232821.ga24...@chakra.karan.org>
Content-Type: text/plain; charset=us-ascii


CentOS Errata and Security Advisory 2016:1217 Critical

Upstream details at : https://rhn.redhat.com/errata/RHSA-2016-1217.html

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

i386:
4f682310ef08803318d69e406dac5beab8bc046daf8e66ac5c1c4f95e373  
firefox-45.2.0-1.el5.centos.i386.rpm

x86_64:
4f682310ef08803318d69e406dac5beab8bc046daf8e66ac5c1c4f95e373  
firefox-45.2.0-1.el5.centos.i386.rpm
95a69b243ad4569af34a05fc1806d826a665a38550abe275f93de0b4378ddf95  
firefox-45.2.0-1.el5.centos.x86_64.rpm

Source:
02393904e04805e7f719e8b2d47d0f63a639e788a7c0f9f9df13826db83edb74  
firefox-45.2.0-1.el5.centos.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: JohnnyCentOS



--

Message: 4
Date: Thu, 16 Jun 2016 15:30:39 

Re: [CentOS] Today's firefox update

[Johnny Hughes]

On 06/17/2016 01:42 AM, Frank Cox wrote:
> On Fri, 17 Jun 2016 07:32:19 +0100
> Ned Slider wrote:
> 
>>> Johnny's announcement refers to:
>>> firefox-45.2.0-1.el5.centos.src.rpm
>>> firefox-45.2.0-1.el6.centos.src.rpm
>>> firefox-45.2.0-1.el7.centos.src.rpm
>>>
>>> The linked rhel webpage refers to:
>>> firefox-45.2.0-1.el5_11.src.rpm
>>> firefox-45.2.0-1.el6_8.src.rpm
>>> firefox-45.2.0-1.el7_2.src.rpm
>>>
>>> These do not appear to be the same thing.  Note the numbers just before
>>> the .src part of the filenames.
>>>
>>
>> CentOS drop the underscore part of the dist tag when they rebuild them. 
>> Checking the changelog should confirm they are the same.
> 
> But we already had a firefox-45.2.0-1 rpm issued a week back:
> 
> $ rpm -qi firefox
> Name: firefox
> Version : 45.2.0
> Release : 1.el7.centos
> Architecture: x86_64
> Install Date: Wed 08 Jun 2016 08:26:44 PM CST
> Group   : Applications/Internet
> Size: 149250172
> License : MPLv1.1 or GPLv2+ or LGPLv2+
> Signature   : RSA/SHA256, Wed 08 Jun 2016 05:19:42 PM CST, Key ID 
> 24c6a8a7f4a80eb5
> Source RPM  : firefox-45.2.0-1.el7.centos.src.rpm
> 
> Therefore, yum won't find this latest update (as far as I can tell, anyway).
> 

Yes .. the announcements were stuck in the outbound queue .. and the
CentOS-7 one had to be regenerated.  The actual RPMs where released last
week when they were built. (The announcements were delayed).

When the CentOS team changes a package for debranding, except the kernel
which has to have the exact same name for 3rd Party Modules or Drivers,
we change the dist tag to .el7.centos (or .el6.centos or .el5.centos).
We do this to denote that the package has been modified.

We only modify packages in the BASE operating system for debranding to
meet the redistribution requirements of Red Hat Software (Specifically,
see the Trademark information here):

https://www.redhat.com/f/pdf/corp/trademark1.pdf

Thanks,
Johnny Hughes





signature.asc
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Would centos 7 backport this libnl3 header fix

[Harry Mallon]

Hello,

Would CentOS7 consider adding the following patch to libnl3?
https://github.com/thom311/libnl/commit/cdf2d4baf376e4a3030a2c1169516358b4fba2e5

g++ fails to build against the headers in the default devel package at the 
moment so I am having to package my own. The patch is very small and easily 
applies on top of the c7 branch from the RPM git. 
https://git.centos.org/summary/rpms!libnl3.git

Harry

Harry Mallon

CODEX | Software Engineer

60 Poland Street | London | England | W1F 7NT

E ha...@codexdigital.com | T +44 203 7000 
989

Website | Facebook 
| Twitter

[http://www.codexdigital.com/?action=asset=E55D8A6F-AF62-4978-8FF1-435A85AFADBF]
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Error: Could not find or load main class with OpenJDK and Oracle Java

[Alexander Farber]

Hello fellow Linux users,

on CentOS 7.2 I have successfully downloaded and installed Oracle Java [1]
with:

# rpm -Uvh jdk-8u91-linux-x64.rpm

Also there is already OpenJDK installed:

# rpm -qa | grep -i jdk
java-1.8.0-openjdk-headless-1.8.0.91-0.b14.el7_2.x86_64
java-1.8.0-openjdk-1.8.0.91-0.b14.el7_2.x86_64
jdk1.8.0_91-1.8.0_91-fcs.x86_64

I can switch between the 2 using this command:

# alternatives --config java

There are 2 programs which provide 'java'.

  SelectionCommand
---
*  1
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.91-0.b14.el7_2.x86_64/jre/bin/java
 + 2 /usr/java/jdk1.8.0_91/jre/bin/java

Enter to keep the current selection[+], or type selection number:

And see the selected version with:

# java -version
java version "1.8.0_91"
Java(TM) SE Runtime Environment (build 1.8.0_91-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode)

# javac -version
javac 1.8.0_91

Now to my problem please -

I have created a simple java file named TheClassName.java:

package thepackagename;

public class TheClassName {
public static final void main(String[] args)  {
System.out.println("Hello World!");
}
}

After successfully compiling it with "javac TheClassName.java"
(which produces TheClassName.class file in the same dir)
I unfortunately can not run it:

# java -cp . thepackagename.TheClassName
Error: Could not find or load main class thepackagename.TheClassName

Here another try:

# export
JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.91-0.b14.el7_2.x86_64/jre

# $JAVA_HOME/bin/java -cp . thepackagename.TheClassName
Error: Could not find or load main class thepackagename.TheClassName

Setting another environment variable does not help either:

# export CLASSPATH=.

Similar command on Windows 7 works well and I have tried
copying the TheClassName.class file from there to Linux too.

The setting is SELINUX=disabled and the server
was installed few weeks ago, serving (without errors) as
LAMP with MySQL/PostgreSQL/Apache/WordPress.

Any suggestions please, have I missed anything?

Regards
Alex

  [1]: http://www.oracle.com/technetwork/java/javase/
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] yum timeout ... (CentOS 6.8)

[Walter H.]

On 16.06.2016 21:59, Tony Schreiner wrote:

I note that duke.edu matches uk, and unl.edu matches nl.

Maybe they are regular expressions,
i just tried with

#include_ony=\.nl,\.de

and got less surprising results




I tried this:

include_only=\.at,\.ch,\.de,\.nl,\.uk

and got this:

Determining fastest mirrors
 * base: mirrors.usinternet.com
Including mirror: mirror.chpc.utah.edu
 * epel: mirror.chpc.utah.edu
 * extras: mirrors.usinternet.com
 * updates: mirrors.usinternet.com

when using this:

include_only=\.at$,\.ch$,\.de$,\.nl$,\.uk$

I got this:

Determining fastest mirrors
 * base: mirrors.usinternet.com
 * epel: mirror.math.princeton.edu
 * extras: mirrors.usinternet.com
 * updates: mirrors.usinternet.com

when using these two lines

exclude=.edu,.com
include_only=\.at$,\.ch$,\.de$,\.nl$,\.uk$

I got this:

Determining fastest mirrors
 * base: mirrors.liquidweb.com
 * epel: linux.mirrors.es.net
 * extras: mirrors.liquidweb.com
 * updates: mirrors.liquidweb.com

quite strange ...

Thanks,
Walter

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Today's firefox update

[Frank Cox]

On Fri, 17 Jun 2016 07:32:19 +0100
Ned Slider wrote:

> > Johnny's announcement refers to:
> > firefox-45.2.0-1.el5.centos.src.rpm
> > firefox-45.2.0-1.el6.centos.src.rpm
> > firefox-45.2.0-1.el7.centos.src.rpm
> >
> > The linked rhel webpage refers to:
> > firefox-45.2.0-1.el5_11.src.rpm
> > firefox-45.2.0-1.el6_8.src.rpm
> > firefox-45.2.0-1.el7_2.src.rpm
> >
> > These do not appear to be the same thing.  Note the numbers just before
> > the .src part of the filenames.
> >
> 
> CentOS drop the underscore part of the dist tag when they rebuild them. 
> Checking the changelog should confirm they are the same.

But we already had a firefox-45.2.0-1 rpm issued a week back:

$ rpm -qi firefox
Name: firefox
Version : 45.2.0
Release : 1.el7.centos
Architecture: x86_64
Install Date: Wed 08 Jun 2016 08:26:44 PM CST
Group   : Applications/Internet
Size: 149250172
License : MPLv1.1 or GPLv2+ or LGPLv2+
Signature   : RSA/SHA256, Wed 08 Jun 2016 05:19:42 PM CST, Key ID 
24c6a8a7f4a80eb5
Source RPM  : firefox-45.2.0-1.el7.centos.src.rpm

Therefore, yum won't find this latest update (as far as I can tell, anyway).

-- 
MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Today's firefox update

[Ned Slider]

On 17/06/16 04:18, Frank Cox wrote:

Johnny's announcement refers to:
firefox-45.2.0-1.el5.centos.src.rpm
firefox-45.2.0-1.el6.centos.src.rpm
firefox-45.2.0-1.el7.centos.src.rpm

The linked rhel webpage refers to:
firefox-45.2.0-1.el5_11.src.rpm
firefox-45.2.0-1.el6_8.src.rpm
firefox-45.2.0-1.el7_2.src.rpm

These do not appear to be the same thing.  Note the numbers just before the 
.src part of the filenames.



CentOS drop the underscore part of the dist tag when they rebuild them. 
Checking the changelog should confirm they are the same.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos