public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Fireinfo reports 41.68% of all reporting installations running on Core Update 134
Date: Mon, 05 Aug 2019 17:18:53 +0100	[thread overview]
Message-ID: <0F0106CF-50E0-4A92-BDE1-3FADF0E1BA2F@ipfire.org> (raw)
In-Reply-To: <0fb162e4-ac35-3f5d-2e02-6b45543ada93@ipfire.org>

[-- Attachment #1: Type: text/plain, Size: 3064 bytes --]

Hi,

> On 4 Aug 2019, at 09:42, Peter Müller <peter.mueller(a)ipfire.org> wrote:
> 
> Hello Michael, hello *,
> 
> sorry for the late reply.
> 
>> Lol, yeah I know why this is.
>> 
>> We have probably the same problem with dns.lightningwirelabs.com where Daniel contacted me yesterday that a system with Core Update 125 was unable to update its DNS record.
> That is interesting as Fireinfo reports 2.28% of reporting installations
> running on this Core Update. Do you have more information why these might
> be unable to report?

Did those maybe submit an update before the 14 days deadline?

>> 
>> Those systems simply use an outdated version of OpenSSL and we require TLS 1.2 or better with all the bells and whistles. We might have to downgrade that to catch all fireinfo profiles.
> Even OpenSSL 1.0.x is capable of TLS 1.2, and I think Core Update 125 is
> using that version branch. Either way, this would mean all installations are
> able to report, or none is. But ~ 2.3% is somewhat in between... :-|

The profiles will only go away when they have not been updated in 14 days.

>> 
>> Some really old systems will send via HTTP and we won’t upgrade them to HTTPS because the whole profile has of course already been transmitted.
>> 
>> Suggestions on what to do?
> Actually, we never had reliable data in Fireinfo. Partial due to reporting
> being a opt-in function (and I know a lot of people leaving this disabled),
> partial due to outdated installations being unable to report anymore.
> 
> Needless to say, I think Fireinfo is valuable, and it should be an opt-in,
> anyway. But we have to bear in mind its only a fraction we talk about,
> and perhaps there is a chance to enumerate how large it is.
> 
> I do not see any need for technical changes here, i.e. allowing TLS 1.0 or
> something.

Is it the ECSDA certificate? Or that we do not support anything but an ECC key exchange? PFS?

> 
> Thanks, and best regards,
> Peter Müller
>> 
>> -Michael
>> 
>>> On 30 Jul 2019, at 17:59, Peter Müller <peter.mueller(a)ipfire.org> wrote:
>>> 
>>> Hello *,
>>> 
>>> having a look at the Fireinfo statistics every now and then
>>> (https://fireinfo.ipfire.org/), I just noticed 41.68% of all
>>> reporting installations are running on the latest Core Update.
>>> 
>>> As far as I am concerned, that number is pleasing, but we
>>> used to have fractions of ~ 33.00% here. So, people are either
>>> installing updates faster than they did in the past (I rather
>>> doubt it) or many (heavily) outdated installations disappeared.
>>> 
>>> On the other hand, due to datacenter migration issues, we
>>> are behind the normal release schedule - thus giving admins
>>> more time to update to the current version.
>>> 
>>> Just thought you might find this interesting.
>>> 
>>> Thanks, and best regards,
>>> Peter Müller
>>> -- 
>>> The road to Hades is easy to travel.
>>> 	-- Bion of Borysthenes
>> 
> 
> -- 
> The road to Hades is easy to travel.
> 	-- Bion of Borysthenes


  reply	other threads:[~2019-08-05 16:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <BC0C0C84-3AA9-4011-8602-549DD2BFA35B@ipfire.org>
2019-08-04  8:42 ` Peter Müller
2019-08-05 16:18   ` Michael Tremer [this message]
2019-07-30 16:59 Peter Müller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0F0106CF-50E0-4A92-BDE1-3FADF0E1BA2F@ipfire.org \
    --to=michael.tremer@ipfire.org \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox