Discuss June 2016

discuss@lists.centos.org

114 participants
99 discussions

CentOS-announce Digest, Vol 136, Issue 4
by centos-announce-request＠centos.org 22 Jun '16

22 Jun '16

Send CentOS-announce mailing list submissions to centos-announce(a)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-request(a)centos.org You can reach the person managing the list at centos-announce-owner(a)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. CEBA-2016:1266 CentOS 6 tzdata BugFix Update (Johnny Hughes) 2. CEBA-2016:1266 CentOS 7 tzdata BugFix Update (Johnny Hughes) 3. CESA-2016:1267 Important CentOS 6 setroubleshoot-plugins Security Update (Johnny Hughes) 4. CESA-2016:1267 Important CentOS 6 setroubleshoot Security Update (Johnny Hughes) 5. CEBA-2016:1266 CentOS 5 tzdata BugFix Update (Johnny Hughes) ---------------------------------------------------------------------- Message: 1 Date: Tue, 21 Jun 2016 18:43:34 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CEBA-2016:1266 CentOS 6 tzdata BugFix Update Message-ID: <20160621184334.GA56003(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2016:1266 Upstream details at : https://rhn.redhat.com/errata/RHBA-2016-1266.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 27275c88c15db6a83722068e6f998d74ccc00bafbb2a80cb4590b47b6ed9e5a2 tzdata-2016e-1.el6.noarch.rpm df6503b270368fa7f3b9147637e423ca6db45485f03072e9d5e273409d782007 tzdata-java-2016e-1.el6.noarch.rpm x86_64: 27275c88c15db6a83722068e6f998d74ccc00bafbb2a80cb4590b47b6ed9e5a2 tzdata-2016e-1.el6.noarch.rpm df6503b270368fa7f3b9147637e423ca6db45485f03072e9d5e273409d782007 tzdata-java-2016e-1.el6.noarch.rpm Source: 65814adef78cc1939847dc32f5ffbce8db34fc58acd8f1a002e002f5917ea638 tzdata-2016e-1.el6.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net Twitter: @JohnnyCentOS ------------------------------ Message: 2 Date: Tue, 21 Jun 2016 19:05:22 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CEBA-2016:1266 CentOS 7 tzdata BugFix Update Message-ID: <20160621190522.GA59766(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2016:1266 Upstream details at : https://rhn.redhat.com/errata/RHBA-2016-1266.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 35e627912852d34e84ea76e5cbcadf233c7945185320fc0a8b2fa7e5e4ee2099 tzdata-2016e-1.el7.noarch.rpm 688596a9be955e0f481845db5b41da2232ef701d56967971e2fe382be32fdad4 tzdata-java-2016e-1.el7.noarch.rpm Source: 32bbb097ae98767d8b45e3b38f03ae1c205eecaef6d1bcd58912fd6f5443a5fb tzdata-2016e-1.el7.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net Twitter: @JohnnyCentOS ------------------------------ Message: 3 Date: Tue, 21 Jun 2016 19:07:23 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CESA-2016:1267 Important CentOS 6 setroubleshoot-plugins Security Update Message-ID: <20160621190723.GA60050(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2016:1267 Important Upstream details at : https://rhn.redhat.com/errata/RHSA-2016-1267.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 3b8bbdeaf83bf2ae720395dd7ea13c3946f439e85bc60731f54414d85beb8a90 setroubleshoot-plugins-3.0.40-3.1.el6_8.noarch.rpm x86_64: 3b8bbdeaf83bf2ae720395dd7ea13c3946f439e85bc60731f54414d85beb8a90 setroubleshoot-plugins-3.0.40-3.1.el6_8.noarch.rpm Source: 524e4dac899bb14f96404df56f34475e037b4c9c770db40b4e039a05b5b1804f setroubleshoot-plugins-3.0.40-3.1.el6_8.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net Twitter: @JohnnyCentOS ------------------------------ Message: 4 Date: Tue, 21 Jun 2016 19:07:49 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CESA-2016:1267 Important CentOS 6 setroubleshoot Security Update Message-ID: <20160621190749.GA60273(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2016:1267 Important Upstream details at : https://rhn.redhat.com/errata/RHSA-2016-1267.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 6162d2040eee1d468be25455dff5505b881b0e843848a0d770b47f8f7b6de9fe setroubleshoot-3.0.47-12.el6_8.i686.rpm 711deca2ead9d099e1ca7f7a951902a3c7380ba0afa701870a280d23a7cbce89 setroubleshoot-doc-3.0.47-12.el6_8.i686.rpm 856cbc9cbfd54ebc46934f28aff9b56779aabc387ca4ecd5ebb0457572cf056e setroubleshoot-server-3.0.47-12.el6_8.i686.rpm x86_64: f108837ced085b3b45952528799c88f53bd1203d7e2f46e65c21a2ef9baa44ed setroubleshoot-3.0.47-12.el6_8.x86_64.rpm 0a76b22ee3f5d8bdcec67c3def7496f7c276c77db4bf23ac6cd5a208ed066260 setroubleshoot-doc-3.0.47-12.el6_8.x86_64.rpm 8a91304bb9f4f120a78858f5e18555b43027997923b0a3a73bdaa2b3c5ecabb4 setroubleshoot-server-3.0.47-12.el6_8.x86_64.rpm Source: 64dea800d736c50ce5d72c06dad0cfb36857a46254d84f01131bd2a09da549d5 setroubleshoot-3.0.47-12.el6_8.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net Twitter: @JohnnyCentOS ------------------------------ Message: 5 Date: Tue, 21 Jun 2016 19:09:43 +0000 From: Johnny Hughes <johnny(a)centos.org> To: centos-announce(a)centos.org Subject: [CentOS-announce] CEBA-2016:1266 CentOS 5 tzdata BugFix Update Message-ID: <20160621190943.GA27729(a)chakra.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2016:1266 Upstream details at : https://rhn.redhat.com/errata/RHBA-2016-1266.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 980470351aa45a505738913c6b98e22543d182acb91410d9d23adcd5ce22efa4 tzdata-2016e-1.el5.i386.rpm f1ab933aec64ab8335388d2dc170670e6842c1828da3d9e6761d6ea4653bb729 tzdata-java-2016e-1.el5.i386.rpm x86_64: 14eea96779590f3a0a341ac8e144377cc2f5327c6e3df6d2757daf0e6a753123 tzdata-2016e-1.el5.x86_64.rpm 27051668651683bf9255059ca73b75ad2a42dee0b97c38065f073feee90fdd25 tzdata-java-2016e-1.el5.x86_64.rpm Source: 2be0737a89567aab8fa13639cfd0f98a04e6f2b337d5604e470ca5d44740f557 tzdata-2016e-1.el5.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net Twitter: JohnnyCentOS ------------------------------ _______________________________________________ CentOS-announce mailing list CentOS-announce(a)centos.org https://lists.centos.org/mailman/listinfo/centos-announce End of CentOS-announce Digest, Vol 136, Issue 4 ***********************************************

1 0

Any further developments on CentOS7 for i386?
by Kay Schenk 22 Jun '16

22 Jun '16

Well I haven't tested out the CentOS 7 for i386 yet as sent in the message of 06/02-- https://lists.centos.org/pipermail/centos-devel/2015-June/013426.html Nor have I seen any additional information. So how is this going? I'm almost ready to jump in as I would really prefer to be on Gnome 3. -- -------------------------------------------- MzK “The journey of a thousand miles begins with a single step.” --Lao Tzu

3 7

Package NetworkManager-libreswan-0.9.8.0-5.el7.x86_64.rpm is not signed
by Jules Bashizi 21 Jun '16

21 Jun '16

How to inst that Network manager please ================ Worthy agent of Light ================ Jules Irenge MSc Student University of Liverpool

4 3

Redirecting port 8080 to port 80 - how to add in /etc/sysconfig/iptables file?
by Alexander Farber 21 Jun '16

21 Jun '16

Good evening, on a CentOS 7 LAMP (not gateway) dedicated server I am using iptables-services with the following /etc/sysconfig/iptables: *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [294:35064] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -p icmp -m icmp --icmp-type any -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp -m multiport --dports 25,80,443,8080 -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 2/min --limit-burst 1 -j ACCEPT COMMIT Also I am running Jetty as user "nobody" at the port 8080 using the /etc/systemd/system/websocket-handler.service file: [Unit] Description=WebSocket Handler Service After=network-online.target [Service] Type=simple User=nobody Group=nobody ExecStart=/usr/bin/java -classpath '/usr/share/java/jetty/*' de.afarber.MyHandler 144.76.184.151:8080 ExecStop=/bin/kill ${MAINPID} SuccessExitStatus=143 [Install] WantedBy=multi-user.target However I actually need my Jetty program to run at port 80 - so that users behind corporate firewalls can connect too. The Jetty doc at https://www.eclipse.org/jetty/documentation/current/setting-port80-access.h… suggests to run the command # iptables -t nat -I PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080 but I can not figure out the corresponding line for the /etc/sysconfig/iptables I have tried running the above command and then "iptables -S" to see the added rule, but that didn't really work. Thank you Alex

6 11

Pulling in broadwell support for cent6u5
by jsl6uy js16uy 21 Jun '16

21 Jun '16

Hello, all. Hope all is well Is it possible to install kernel and support files from 6u7 into a base 6u5 image to achieve full broadwell support in 6u5? We are "locked", clearly not fully since willing to up jump kernels, on 6u5. Thanks for any and all help

4 7

Re: [CentOS] https and self signed
by James B. Byrne 21 Jun '16

21 Jun '16

On Mon, June 20, 2016 13:16, Gordon Messmer wrote: > On 06/20/2016 07:47 AM, James B. Byrne wrote: >> On Sat, June 18, 2016 18:39, Gordon Messmer wrote: >> >>> I'm not interested in turning this in to a discussion on >>> epistemology. >>> This is based on the experience (the evidence) of some of the >>> world's foremost experts in the field (Akamai, Cisco, EFF, >>> Mozilla, etc). I would rather look to Bruce Schneier and Noam Chomsky for guidance before I would take security advice from organisations that have already shown to be compromised in the matters of their clients' security -- the EFF being the sole exception in the list provided. Or so I presently believe. >> Really? Then why did you forward your reply a private message to a >> public mailing list if not to do exactly what you claim you wish to >> avoid? > > Accidents happen. I didn't intentionally mail you off-list, > and when I noticed that I had, seconds later, I re-sent the > message to the list, expecting that you'd notice and understand > that I intended to keep the conversation on the list. > Except that I get the list as a digest. Which means that your assumptions were wrong. Funny that think you not? > ..which isn't relevant to the question of what you consider "evidence" > of security practice implications. > > Look, go to https://www.google.com/ right now and tell me what you > see. A snoop that self-signs its own certificates? > Do you suddenly distrust the internet's single largest domain? Do you > think they implement poor security practices? > My distrust of Google developed over many years. There was nothing sudden about it. But it is deep now. >>> For someone who wants "evidence" you make a lot of unsupported >>> assertions. You do see the irony, don't you? I assert my opinions if that is what you are referring to. I do not claim them to be fact. I believe them to be true but I admit readily that I may be wrong. Indeed I most certainly must be wrong in some of them. My difficulty begin determining which ones. However, I have formed my opinions on the basis of a long term exposure to security matters both pre and post Internet. And I have seen before the same thoughtless enthusiasms for things shiny and different in the security community. Things adopted and put into practice without even the most cursory of trials and evaluations for effectiveness and efficacy -- not to mention lawfulness on some occasions --. Sometimes I have had to deal with the consequences of those choices at the pointy end of the stick. Thus if I am to adopt a different point of view then I require something in the way of supporting measurable evidence to show that I am wrong and that others are right. >> The difference is that I state this is my opinion and I do not claim >> it as a fact. Your statement claimed a factual basis. I was >> naturally curious to see what evidence supported your claim. > > Citation required. > > Allow me an example. To quote you: > "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." > > Now, when you asked "what possible benefit accrues from changing > secured device keys on a frequent basis?" I pointed you to > letsencrypt's documentation, which describes the benefits of > 90-day certificates. Having actual software in the possession of users rendered unusable by a policy decision implemented in the name of security is not beneficial. Referring to others self-justification of measures they have already implemented is not evidence. It is argument. Which has its place providing that one accepts the fundamental postulates of the positions being argued. These, in this case, require evidence. Assertions that these measures solve certain perceived flaws without addressing the costs of those measures is a one-side argument and not very convincing in my opinion. Refusing to deal with that is simply ignoring the elephant in the room. > > So, please describe how I am "claiming a factual basis" while you are > not. > >> Automated security is BS. It has always been BS and it always will >> be BS. That is my OPINION. It may not be a fact for I lack >> empirical evidence to support it. However, it has long been my >> observation that when people place excessive trust in automation >> they are are eventually and inevitably betrayed by it. Often at >> enormous cost. > > This is what I consider "enormous cost": > https://en.wikipedia.org/wiki/Heartbleed#Certificate_renewal_and_revocation > > After a major security bug which exposed private keys, hundreds of > thousands of servers did not take the required action to secure their > services, and the vast majority of those that took *some* action did > it incorrectly and did not resolve the problem. > > Had those sites been using letsencrypt and renewing automatically, > the exposed keys would have been replaced within 90 days > (typically 60 max, so 30 days on average). Instead, it is likely > that the problem will remain a risk for "months, if not years, to > come." > > And that's empirical evidence, which you have yet to offer. Again, you miss the point. I am not offering evidence of something that I am claiming as fact. I am seeking evidence in support of what someone else is claiming as fact. Evading the question may be a good rhetorical technique but it is hardly science. And your 'evidence' as presented above presupposes a number of unspoken assumptions. Some of which I fear would not stand scrutiny. The consequences of Heartbleed are well known to me. I had to tear down and re-establish our entire PKI because of it. However, anecdotal references to specific cases where a particular practice might, and let us remember that HB was out in the wild being exploited for at least two years before being publicly revealed, just might have provided some protection in some cases does not prove anything. In the case cited I do not believe changing certificates on an hourly basis would have made much difference against an technically proficient attacker exploiting the weakness. It is well to recall how HB came to be. A misguided attempt at an improvement in protocol exchange which amounted to not much more than gilding-the-lily and which since has been discarded without noticeable loss. What prevents similarly motivated 'improvements' to an automated certificate authority from having equally damaging effects on the robustness of the the certificates that they provide? We trusted OpenSSL because it was open. How do you trust an organisation's internal practices once they have been automated? Does anyone here actually believe that once in production this automation is or will be adequately documented? Or that said documentation will be rigourously maintained up-to-date? Or that independent and competent audits will be regularly conducted without notice? I take particular care with my PKI. I rebuild all the moduli for ssh on all of our servers for SSH. Because I trust no-one with my security. And that includes RedHat and any other external organisation, volunteer or commercial, open-source or proprietary. Automating your certificate replacement and entrusting it to an outside provider is begging to have some state actor or other financially powerful group subvert it. Look at what the NSA pulled off with RSA. That was for just money. What about patriotism? What would a true believer do if asked by his state and they were in a position to act? Think of the security nightmare that would result from having the certificate production of an automated 90 day certificate authority tampered with and left undetected for even a modest amount of time, say 180 days. At its core security is about risk analysis. And at the core of risk analysis is cost/benefit analysis. If the cost of a security measure exceeds the value of what is being secured then it makes no sense. I am seeking that cost-benefit analysis for short term certificates. And I have not seen anything in the way of objective evidence that supports the assertion that short-term certificates, or passwords for that matter, provide any measurable security benefit other than the feel-good sense that "at least its something". For one thing, this position presupposes that the rest of your security is so bad that frequent key compromise is inevitable. For another is assumes that the cost to users having to constantly deal with change is negligible. I run a business. Let me assure you that the cost of change is never negligible. > >> This impediment however is strictly an artefact of signing code with >> short term certificates. I simply had to reset the date on my MB >> back to some future date when the certificate was valid and >> everything worked fine. > > Apple's intermediate certs have a 10 year lifetime. If you consider > that "short term" then I fear that nothing is suitable in your > opinion. Apple evidently did not use those certificates to sign their software in this case. So you point is irrelevant even if it may be true. > >> But hey, what is my time worth in comparison to the security those >> certificates provided? SECURITY that was trivially evaded in the >> end. > > Fixing your clock is not "evading" security. Setting a clock backwards in time by two years is 'fixing it'? A curious point of view in my opinion. > >> Exactly what mindless person or committee of bike-shedders decided >> that software should be distributed so that copies of it expire? > > Expiration is a fundamental aspect of x509 certificates. Do you > understand x509 at all? Expiry is a fundamental part of many things including life itself. That does not imply that shorter is better. Why sign software with an expiry date when you know that your recovery programme will fail to operate after it expires? Imagine that you are on a hospital operating table and the defibrillators fail to function because the certificate that signed the firmware has expired. And that the immediate the fix is to simply reset the computer clock in the defibrillator controller backwards in time. Which of course no-one in the OR knows. So, too bad. But, you were secure when you expired. There is absolutely no sensible reason why the recovery software could not have simply warned me that the signature had expired and then asked me if I wished to proceed regardless. Having made the design decision that it would not do so then it was incumbent on the organisation responsible to allow people to override it. Instead they offer up some weasel-worded warning about "TAMPERING" and "CORRUPTION". Just what a person in the middle of system recovery is waiting to hear. Most of what passes for informed opinion about security is folk remedy dressed up with techno-babble and pushed onto an audience mostly too embarrassed to admit that they do not understand what is being talked about. In my opinion of course. However, decisions having real consequences are made on the basis of such ignorant acceptance of received wisdom. Therefore I think it important to challenge those that assert such things to produce convincing evidence that what they say is so. I understand that you believe that short term certificates and passwords and such provide a measure of security. That very well may be the case. I am not trying to convince you otherwise. All I ask for is a reasonable explanation of how much these practices cost those that employ them, how much benefit they provide to those users and what further risks they introduce. Security is a funny sort of thing being mostly based on our fear of the unknown; our too-active imaginations; and our attraction to the spectacular at the cost of dealing adequately with the mundane. At one time an automobile had to be preceded by a pedestrian waving a red flag. This too was done for the general security of all. We do not do it any more so there must have been a reason we stopped. I suggest that it was because the evidence did not support a positive cost/benefit analysis. But it sure sounded reasonable at the time to people that had little or no experience with automobiles. YMMV. -- *** 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. Byrne mailto:ByrneJB@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

1 0

CentOS 6 + nux-dextop: GIMP vs. GIMP 2.8 ?
by Nicolas Kovacs 21 Jun '16

21 Jun '16

Hi, I just setup a CentOS 6 desktop with the nux-dextop repository activated. When installing GIMP (yum install gimp), I get a gimp package as well as a gimp28 package. I understand this is the Nux-Dextop GIMP 2.8 package. Unfortunately this doesn't work so well with my system. It's not localized (menus appear in english, though the system is in French), the main GTK theme (Murrina Gilouche) is not managed and the application has that ugly east german look like in the good old GTK1 days, and there are two redundant menu entries, one of which is not responsive. I'd like to be able to install the plain "official" GIMP 2.6 application on my system, but when I try to 'yum remove gimp28', it takes the whole GIMP stuff down the drain with it. Note: I'm already using the Yum Priorities plugin. Official repos (base, updates and extra) are configured with a priority of 1, the other stuff (epel, adobe, nux-dextop) has a priority of 10. Any suggestions? Cheers from the sunny South of France, Niki Kovacs -- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Web : http://www.microlinux.fr Mail : info(a)microlinux.fr Tél. : 04 66 63 10 32

3 5

bad iscsi performance after upgrade to CentOS 7.2
by Ulrich Leodolter 21 Jun '16

21 Jun '16

hi all, after i upgraded a physical server (SUN FIRE X4170) from CentOS 6.8 to 7.2 i am not able to get the same iSCSI read performance. the server is connected to HP P2000 Storage via 2 x 1GbE Ethernet. CentOS 6.8 gives me full read performance on raw iSCSI devices /dev/sdxx at 115MB/s. CentOS 7.2 allows only 90-100MB/s, read performance varies and is not stable like for 6.8 the multipath performance on 7.2 is even worse. CentOS 6.8 allows to read a full speed and stable 220MB/s. CentOS 7.2 maximum was 140MB/s after i disabled readahead for multipath devices in tuned. btw. i tried many recommended optimizations in 7.2, but i am not getting the raw iSCSI read performance than on 6.8, and on 6.8 i had no special tuning für iSCSI. mtu 9000 is set and verified for both OS, other settings like network buffers are almost identical. has anyone an idea why iSCSI read performance degraded in CentOS 7.2 ? best regards ulrich

2 1

https and self signed
by Jerry Geis 21 Jun '16

21 Jun '16

I followed the instructions here https://wiki.centos.org/HowTos/Https Checking port 80 I get the file... curl http://localhost/file.html <HTML> <FORM> Working </FORM> </HTML> Checking port 443 I get and error curl https://localhost/file.html curl: (60) Peer's certificate issuer has been marked as not trusted by the user. More details here: http://curl.haxx.se/docs/sslcerts.html curl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option. If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL). If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option. How do I get past this? I was looking to just self sign for https. Yes I can added the --insecure for curl - but - my other app doesn't seem to work either - perhaps getting the same return message instead of the actual file. Thanks, jerry

13 39

Re: [CentOS] https and self signed
by James B. Byrne 21 Jun '16

21 Jun '16

On Sat, June 18, 2016 18:39, Gordon Messmer wrote: > On 06/18/2016 02:49 PM, James B. Byrne wrote: >> On Fri, June 17, 2016 21:40, Gordon Messmer wrote: >>> https://letsencrypt.org/2015/11/09/why-90-days.html >> With respect citing another person's or people's opinion in support >> of >> your own is not evidence in the sense I understand the word to mean. > > I'm not interested in turning this in to a discussion on epistemology. > This is based on the experience (the evidence) of some of the world's > foremost experts in the field (Akamai, Cisco, EFF, Mozilla, etc). Really? Then why did you forward your reply a private message to a public mailing list if not to do exactly what you claim you wish to avoid? > >> The assertion expressed in the link given above that 90-day >> certificate lives will serve to increase certificate renewal >> automation is at best a pious hope. > > You are ignoring the fact that the tool used to acquire letsencrypt > certificates automates the entire process. They're not merely hoping > that users will automate the process, they're automating it on behalf > of users. They've done everything but schedule it for their users. > >> One that is unlikely to be >> realised in my opinion for the simple reason that automated and >> therefore mostly unobserved security systems are a primary target >> for tampering. > > For someone who wants "evidence" you make a lot of unsupported > assertions. You do see the irony, don't you? The difference is that I state this is my opinion and I do not claim it as a fact. Your statement claimed a factual basis. I was naturally curious to see what evidence supported your claim. > >> Likewise the authors' opinion that pki certificates are in >> general just casually left laying around to be compromised displays >> a >> certain level of what reasonably could be considered elitist >> contempt >> for the average human's intelligence. > > Or, you know, a review of actual security problems in the real world. > >> Even as arguments I find these two positions are less than >> compelling. >> And in no respect could either opinion be considered evidence. > > That's fine. I don't really need to convince you, personally, of > anything. But for the security of the internet community in general, > I'll continue to advocate for secure practices, including pervasive > security (which means reducing barriers to the use of encryption at > all points along the process of setup). > > I know, and we put infants on no-fly lists for essentially the same religious beliefs. The benefit of so-called general security for the rest of us who do not have to bear its individual specific cost. The is no evidence that this sort of stuff works. It is just done so that if anything bad happens the authorities can claim that they did something preventative which they can point to. Regardless of how ineffectual it was. Automated security is BS. It has always been BS and it always will be BS. That is my OPINION. It may not be a fact for I lack empirical evidence to support it. However, it has long been my observation that when people place excessive trust in automation they are are eventually and inevitably betrayed by it. Often at enormous cost. Let me give you an example of stupidity in action with respect to signed certificates. I have a MacBookPro c. early 2009. There have been five or six major releases of OSX since then. Being a cautious type I download the upgrade installer apps and archive them before installing and upgrading. Over this past weekend my MB stopped booting. It would get to the Apple symbol and go black. Much trial, error, and research later I discover that this is sometimes occurs when a MB has been repeatedly upgraded and that a clean install is the recommended cure. Oh, by-the-way, if you ever have to do this then do not use the Apple Migration Assistant app when you are done. You will be sorry. So, I get out my archived Installer app, go to install it and BANG! My MB proclaims that "Somebody has tampered with the application or it is corrupted!". OH NO! This impediment however is strictly an artefact of signing code with short term certificates. I simply had to reset the date on my MB back to some future date when the certificate was valid and everything worked fine. Of course this took me a great deal of frustrating effort to discover what had happened to all of my archived copies and how to fix it. In the middle of a system recovery I might add. But hey, what is my time worth in comparison to the security those certificates provided? SECURITY that was trivially evaded in the end. Exactly what mindless person or committee of bike-shedders decided that software should be distributed so that copies of it expire? What security issue was addressed by this decision? What benefit to the public was achieved? When real people suffer real inconvenience and real loss of productive effort because of mindless adhesion to bromide based cures that are blandly offered for ills that mostly exist in the imagination of the ignorant then yes; I require evidence of their efficacy. And lining up a bunch of band-wagon pundits chanting the same vacuous refrains is not evidence. And this one is going to the list. -- *** 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. Byrne mailto:ByrneJB@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 -- *** 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. Byrne mailto:ByrneJB@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

4 3

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss June 2016