OLC and Cambridge 10/20/25 support ending

[Roy Clark, \B6\]

I was an early (and remain a) strong supporter of the OLC - gave the
first OLC presentation to the Seattle Glider Council (SGC) - for
stimulating growth in cross-country soaring. Check-out the increase
in SGC participation over the life of the OLC!

As a Cambridge 20 user, I lament the end of OLC support. However, I
do not want to replace my Cambridge 20 - L-NAV - PDA with Glide
Navigator II installation.

Getting ready to make my wish list for Santa and would appreciate
recommendations for a back-up system that will likely remain
compatible with the OLC system.

Thanks in advance.

[S. Murry]

Roy,
I've been using XCSoar running on my Android phone. It works great for
OLC, and Santa will be happy beacuse it's free (if you have an Android
device).

Somebody mentioned on here that OLC won't score an XC Soar generated IGC
file for "OLC League" (I think). I'm not sure about this because I've
never tried it. But for logging flight, posting to OLC, and getting
scored it works great.

--Stefan

On Sat, 03 Dec 2011 11:59:54 -0600, Roy Clark, "B6" >
wrote:

> I was an early (and remain a) strong supporter of the OLC - gave the
> first OLC presentation to the Seattle Glider Council (SGC) - for
> stimulating growth in cross-country soaring. Check-out the increase
> in SGC participation over the life of the OLC!
>
> As a Cambridge 20 user, I lament the end of OLC support. However, I
> do not want to replace my Cambridge 20 - L-NAV - PDA with Glide
> Navigator II installation.
>
> Getting ready to make my wish list for Santa and would appreciate
> recommendations for a back-up system that will likely remain
> compatible with the OLC system.
>
> Thanks in advance.
>


--
Stefan Murry

[Bob]

On Dec 3, 10:59*am, "Roy Clark, \"B6\"" > wrote:
> I was an early (and remain a) strong supporter of the OLC - gave the
> first OLC presentation to the Seattle Glider Council (SGC) *- *for
> stimulating growth in cross-country soaring. *Check-out the increase
> in SGC participation over the life of the OLC!
>
> As a Cambridge 20 user, I lament the end of OLC support. *However, I
> do not want to replace my Cambridge 20 - L-NAV - PDA with Glide
> Navigator II installation.
>
> Getting ready to make my wish list for Santa and would appreciate
> recommendations for a back-up system that will likely remain
> compatible with the OLC system.
>
> Thanks in advance.

The stand-alone flywithce recorder is very small and very inexpensive,
and it works for OLC.

[Ramy]

On Dec 3, 12:45*pm, Bob > wrote:
> On Dec 3, 10:59*am, "Roy Clark, \"B6\"" > wrote:
>
> > I was an early (and remain a) strong supporter of the OLC - gave the
> > first OLC presentation to the Seattle Glider Council (SGC) *- *for
> > stimulating growth in cross-country soaring. *Check-out the increase
> > in SGC participation over the life of the OLC!
>
> > As a Cambridge 20 user, I lament the end of OLC support. *However, I
> > do not want to replace my Cambridge 20 - L-NAV - PDA with Glide
> > Navigator II installation.
>
> > Getting ready to make my wish list for Santa and would appreciate
> > recommendations for a back-up system that will likely remain
> > compatible with the OLC system.
>
> > Thanks in advance.
>
> The stand-alone flywithce recorder is very small and very inexpensive,
> and it works for OLC.

I believe just about every flight computer software generates an OLC
compatible IGC file, unless you fly a motorglider and need ENL
(workaround is to claim as pure glider with the same handicap
instead...)

Ramy

[4Q]

On Dec 3, 11:08*pm, Ramy > wrote:
> On Dec 3, 12:45*pm, Bob > wrote:
>
>
>
>
>
> > On Dec 3, 10:59*am, "Roy Clark, \"B6\"" > wrote:
>
> > > I was an early (and remain a) strong supporter of the OLC - gave the
> > > first OLC presentation to the Seattle Glider Council (SGC) *- *for
> > > stimulating growth in cross-country soaring. *Check-out the increase
> > > in SGC participation over the life of the OLC!
>
> > > As a Cambridge 20 user, I lament the end of OLC support. *However, I
> > > do not want to replace my Cambridge 20 - L-NAV - PDA with Glide
> > > Navigator II installation.
>
> > > Getting ready to make my wish list for Santa and would appreciate
> > > recommendations for a back-up system that will likely remain
> > > compatible with the OLC system.
>
> > > Thanks in advance.
>
> > The stand-alone flywithce recorder is very small and very inexpensive,
> > and it works for OLC.
>
> I believe just about every flight computer software generates an OLC
> compatible IGC file, unless you fly a motorglider and need ENL
> (workaround is to claim as pure glider with the same handicap
> instead...)
>
> Ramy- Hide quoted text -
>
> - Show quoted text -

hi Roy
I think the power flarm is an igc approved logger???????????? 4Q

[Frank Paynter[_2_]]

On Dec 3, 12:59*pm, "Roy Clark, \"B6\"" > wrote:
> I was an early (and remain a) strong supporter of the OLC - gave the
> first OLC presentation to the Seattle Glider Council (SGC) *- *for
> stimulating growth in cross-country soaring. *Check-out the increase
> in SGC participation over the life of the OLC!
>
> As a Cambridge 20 user, I lament the end of OLC support. *However, I
> do not want to replace my Cambridge 20 - L-NAV - PDA with Glide
> Navigator II installation.
>
> Getting ready to make my wish list for Santa and would appreciate
> recommendations for a back-up system that will likely remain
> compatible with the OLC system.
>
> Thanks in advance.

Check out SoarPilot (http://soaringpilot.org/). It's free and has
known OLC support/registration. It runs natively on any Palm OS
product (best is a Tungsten T/Magellan GPS Companion combination), but
will run on any Windows PDA using StyleTap. Best of all it is free
and is very well supported.

Regards,

Frank (TA)

[Derek Mackie]

I borrowed a Nano as a backup for Uvalde Glide and was impressed with
its simple operation. The Colibri II seems to also be a good option,
though neither are "cheap". The Colibri is currently on sale as they
clear stock. Any of these should be nearly a direct replacement for
the LX20. Inexpensive alternatives are as mentioned above - most of
the current PDA software will generate files acceptable for IGC (GNII
is an exception) and all you need is the GPS source, which you already
have with the LX20.

Cheers,

Derek

[Roy Clark, \B6\]

Thanks to all who have or still will reply.

I'm not interested is changing my current cell phone nor my current
Cambridge 20 - L-Nav - Ipaq running GN II software system.

The Nano seems the easiest of the options so far.

[Tony[_5_]]

On Dec 4, 2:53*pm, "Roy Clark, \"B6\"" > wrote:
> Thanks to all who have or still will reply.
>
> I'm not interested is changing my current cell phone nor my current
> Cambridge 20 - L-Nav - Ipaq running GN II software system.
>
> The Nano seems the easiest of the options so far.

if all you need is a logger to make something to upload to the OLC
then you should go with the FlywithCE. Easy on/off button and that is
all there is to the operation. $120 or so through various vendors.
Nano will come in handy though if you want to go for a world record,
which your Cambridge cannot do. Otherwise you could find something
more productive to do with the extra $400

[Derek Mackie]

> No PDA generated files are acceptable to IGC. Do you mean acceptable to
> OLC?

Oops - Yes. Sorry. I shouldn't start drinking so early... ;-)

Derek

[JohnDeRosa]

On Dec 3, 11:59*am, "Roy Clark, \"B6\"" > wrote:

> As a Cambridge 20 user, I lament the end of OLC support. *However, I
> do not want to replace my Cambridge 20 - L-NAV - PDA with Glide
> Navigator II installation.

What does "end of OLC support" mean? Now or in the near future? I
show at http://www.onlinecontest.org/olc-2.0/OLC-recorder.pdf that the
CAI20 is approved.

This seems odd that OLC doesn't like the CAI20 because the IGC
approved list shows the CAI20 as approved for "Badges (all)" which is
defined as,

"Badges (all) - This applies to types of Recorders that do not fulfil
the Specification in some areas at the time of approval. However, it
has been decided that they may be given an approval that excludes
World Record flights but includes all IGC/FAI Badges and Distance
Diplomas."

So the CAI20 isn't quite as good as an EW Microrecoder, LX Nano or a
CAI 302 (each is approved for "All Flights") but you aren't trying for
a world record so what gives with OLC?

Stupid question - Are you sure you are submitting the correct IGC file
and not a GNII log file? All I have ever done in the past is manually
download the CAI IGC file to my PC (actually done via GNII) and then
manually upload to OLC (direct claim). See
http://www.onlinecontest.org/olc-2.0/Direktmeldung_eng.pdf for
details.

Good luck.

- John

[Tony[_5_]]

On Dec 6, 3:20*pm, JohnDeRosa > wrote:
> On Dec 3, 11:59*am, "Roy Clark, \"B6\"" > wrote:
>
> > As a Cambridge 20 user, I lament the end of OLC support. *However, I
> > do not want to replace my Cambridge 20 - L-NAV - PDA with Glide
> > Navigator II installation.
>
> What does "end of OLC support" mean? *Now or in the near future? * I
> show athttp://www.onlinecontest.org/olc-2.0/OLC-recorder.pdfthat the
> CAI20 is approved.
>
> This seems odd that OLC doesn't like the CAI20 because the IGC
> approved list shows the CAI20 as approved for "Badges (all)" which is
> defined as,
>
> "Badges (all) - This applies to types of Recorders that do not fulfil
> the Specification in some areas at the time of approval. However, it
> has been decided that they may be given an approval that excludes
> World Record flights but includes all IGC/FAI Badges and Distance
> Diplomas."
>
> So the CAI20 isn't quite as good as an EW Microrecoder, LX Nano or a
> CAI 302 (each is approved for "All Flights") but you aren't trying for
> a world record so what gives with OLC?
>
> Stupid question - Are you sure you are submitting the correct IGC file
> and not a GNII log file? *All I have ever done in the past is manually
> download the CAI IGC file to my PC (actually done via GNII) and then
> manually upload to OLC (direct claim). *Seehttp://www.onlinecontest.org/olc-2.0/Direktmeldung_eng.pdffor
> details.
>
> Good luck.
>
> - John
http://www.onlinecontest.org/olc-2.0/segelflugszene/cmsnews.html?month=112011

about half way down, a very short entry.

[Westbender]

On Dec 6, 3:40*pm, Tony > wrote:
> On Dec 6, 3:20*pm, JohnDeRosa > wrote:
>
>
>
> > On Dec 3, 11:59*am, "Roy Clark, \"B6\"" > wrote:
>
> > > As a Cambridge 20 user, I lament the end of OLC support. *However, I
> > > do not want to replace my Cambridge 20 - L-NAV - PDA with Glide
> > > Navigator II installation.
>
> > What does "end of OLC support" mean? *Now or in the near future? * I
> > show athttp://www.onlinecontest.org/olc-2.0/OLC-recorder.pdfthatthe
> > CAI20 is approved.
>
> > This seems odd that OLC doesn't like the CAI20 because the IGC
> > approved list shows the CAI20 as approved for "Badges (all)" which is
> > defined as,
>
> > "Badges (all) - This applies to types of Recorders that do not fulfil
> > the Specification in some areas at the time of approval. However, it
> > has been decided that they may be given an approval that excludes
> > World Record flights but includes all IGC/FAI Badges and Distance
> > Diplomas."
>
> > So the CAI20 isn't quite as good as an EW Microrecoder, LX Nano or a
> > CAI 302 (each is approved for "All Flights") but you aren't trying for
> > a world record so what gives with OLC?
>
> > Stupid question - Are you sure you are submitting the correct IGC file
> > and not a GNII log file? *All I have ever done in the past is manually
> > download the CAI IGC file to my PC (actually done via GNII) and then
> > manually upload to OLC (direct claim). *Seehttp://www.onlinecontest.org/olc-2.0/Direktmeldung_eng.pdffor
> > details.
>
> > Good luck.
>
> > - John
>
> http://www.onlinecontest.org/olc-2.0/segelflugszene/cmsnews.html?mont...
>
> about half way down, a very short entry.- Hide quoted text -
>
> - Show quoted text -

Yep, they just don't want to continue supporting/maintaining that
code. Maybe they lost the source code for that validation routine. You
wouldn't think it would be that big a deal for a software developer to
update it (assuming they have the source). There's something not right
about this whole thing, and they're not saying anything other than "we
give up".

[KevinFinke]

They quote the following...

Tuesday, 08. November
The OLC's support to GPS-Nav/Cambridge 10/20/25 will cease on Dezember
31st
The validation procedure of GPS-Nav/Cambridge 10/20/25 is out of date
since a long time and administring it further is not sustainable. In
efforts to find a solution with representatives from the manufacturer
we could not come to a feasible conclusion. Therefore participation at
the OLC with GPS-Nav/Cambridge 10/20/25 will be only possible until
the end of 2011.
We appologize for any inconvenience and hope for your
understanding ...

Sounds like it's not just an OLC issue. It would require some legacy
support from the current mfg's representatives, and it doesn't seem
like either side was willing to reach an agreement. Don't know what
the issues were, but the soaring community seems to be a very capable
group. Perhaps there is an alternative that could be spearheaded by
the current users.

-Kevin

[Tony[_5_]]

On Dec 6, 4:07*pm, Westbender > wrote:
> On Dec 6, 3:40*pm, Tony > wrote:
>
>
>
> > On Dec 6, 3:20*pm, JohnDeRosa > wrote:
>
> > > On Dec 3, 11:59*am, "Roy Clark, \"B6\"" > wrote:
>
> > > > As a Cambridge 20 user, I lament the end of OLC support. *However, I
> > > > do not want to replace my Cambridge 20 - L-NAV - PDA with Glide
> > > > Navigator II installation.
>
> > > What does "end of OLC support" mean? *Now or in the near future? * I
> > > show athttp://www.onlinecontest.org/olc-2.0/OLC-recorder.pdfthatthe
> > > CAI20 is approved.
>
> > > This seems odd that OLC doesn't like the CAI20 because the IGC
> > > approved list shows the CAI20 as approved for "Badges (all)" which is
> > > defined as,
>
> > > "Badges (all) - This applies to types of Recorders that do not fulfil
> > > the Specification in some areas at the time of approval. However, it
> > > has been decided that they may be given an approval that excludes
> > > World Record flights but includes all IGC/FAI Badges and Distance
> > > Diplomas."
>
> > > So the CAI20 isn't quite as good as an EW Microrecoder, LX Nano or a
> > > CAI 302 (each is approved for "All Flights") but you aren't trying for
> > > a world record so what gives with OLC?
>
> > > Stupid question - Are you sure you are submitting the correct IGC file
> > > and not a GNII log file? *All I have ever done in the past is manually
> > > download the CAI IGC file to my PC (actually done via GNII) and then
> > > manually upload to OLC (direct claim). *Seehttp://www.onlinecontest..org/olc-2.0/Direktmeldung_eng.pdffor
> > > details.
>
> > > Good luck.
>
> > > - John
>
> >http://www.onlinecontest.org/olc-2.0/segelflugszene/cmsnews.html?mont...
>
> > about half way down, a very short entry.- Hide quoted text -
>
> > - Show quoted text -
>
> Yep, they just don't want to continue supporting/maintaining that
> code. Maybe they lost the source code for that validation routine. You
> wouldn't think it would be that big a deal for a software developer to
> update it (assuming they have the source). There's something not right
> about this whole thing, and they're not saying anything other than "we
> give up".

I see ILEC, FLARM, LX Navigation, LXNAV, and Naviter listed on the
right side of the homepage, but not Cambridge...

[Dave Nadler]

On Tuesday, December 6, 2011 6:29:31 PM UTC-5, Tim Newport-Peace wrote:
> ...Nor can I see them releasing the code into the soaring community as this
> would lead to the IGC Approval for these models being rescinded as
> releasing the code also releases the security algorithm.

No, the algorithm and public keys are *already* public,
just disassemble the (existing public IGC DLL for example)
routine.

The only issue is: nobody wants to do the work to support
these old things...

Hope that clears it up,
Best Regards, Dave "YO electric"

[Westbender]

On Dec 6, 4:14*pm, KevinFinke > wrote:
> They quote the following...
>
> Tuesday, 08. November
> The OLC's support to GPS-Nav/Cambridge 10/20/25 will cease on Dezember
> 31st
> The validation procedure of GPS-Nav/Cambridge 10/20/25 is out of date
> since a long time and administring it further is not sustainable. In
> efforts to find a solution with representatives from the manufacturer
> we could not come to a feasible conclusion. Therefore participation at
> the OLC with GPS-Nav/Cambridge 10/20/25 will be only possible until
> the end of 2011.
> We appologize for any inconvenience and hope for your
> understanding ...
>
> Sounds like it's not just an OLC issue. It would require some legacy
> support from the current mfg's representatives, and it doesn't seem
> like either side was willing to reach an agreement. Don't know what
> the issues were, but the soaring community seems to be a very capable
> group. Perhaps there is an alternative that could be spearheaded by
> the current users.
>
> -Kevin

What they mean by "legacy support" is to have "the manufacturer" come
up with a way to produce "authentic" igc files so they can validate
them just like any other.

[Max Kellermann]

Tim Newport-Peace ]> wrote:
> I can't see anyone from the Cambridge side spending any effort in
> producing new code for a product that is no longer in production, even
> if they had the source code and ability to do this.

And that's why manufacturers should always publish their algorithms
and public keys: to allow people to write new validation software when
their product has gone out of production and the old validation
programs will never be adapted to new operating systems.

Now if there only was one single good example among logger
manufacturers, we could put our money where our (long-term) interest
is ..

That some private key may have leaked does not seem to be related,
according to the wording on the OLC web site. I guess the OLC has
switched to Windows-x64 on their servers, and that Windows version is
unable to run DOS validation programs ... Hey, logger manufacturers,
providing a proprietary WIN32 DLL is not a solution, it's just the
next iteration of the same old problem!

Max

[Dave Nadler]

On Wednesday, December 7, 2011 2:08:59 AM UTC-5, Max Kellermann wrote:
> ... Hey, logger manufacturers,
> providing a proprietary WIN32 DLL is not a solution, it's just the
> next iteration of the same old problem!

No, it is complying with the IGC requirements, and supporting
thousands of users via scoring programs, log viewing programs,
etc.

[Max Kellermann]

Dave Nadler > wrote:
> On Wednesday, December 7, 2011 2:08:59 AM UTC-5, Max Kellermann wrote:
>> ... Hey, logger manufacturers,
>> providing a proprietary WIN32 DLL is not a solution, it's just the
>> next iteration of the same old problem!
>
> No, it is complying with the IGC requirements, and supporting
> thousands of users via scoring programs, log viewing programs,
> etc.

What you say may be correct from your point of view, but it has
nothing to do with the argument of my post. You're missing the point.

Today, a WIN32 DLL may be what users need and what IGC requires. In
the 90ies, a DOS program was what users needed and what IGC required,
and that is considered deprecated today, so much deprecated that the
OLC bans a logger that has only a DOS program.

Today's technology will be deprecated tomorrow. Most Windows users
have a 64 bit operating system, and having to support 32 bit DLLs will
constrict technological progress. Windows 8 will run on ARM CPUs, and
that CPU cannot run x32 code. Neither will that DLL be usable on a
Mac, on Linux, on your PDA, on your mobile phone or on your tablet.
The computer world is changing rapidly nowadays. Providing just a
proprietary WIN32 DLL is ignorance, and your anecdotical "thousands of
users" do not matter a lot for that principle, as this is a general
technical problem, not a popularity contest.

If you need a practical example: my logger is a CAI302, and after
landing, XCSoar downloads the IGC file from it. I want XCSoar to
validate the IGC file, but I cannot, because my Streak does not run
Windows and does not have a Intel x32 CPU. I suppose there are
"thousands of users" who would probably like to do some same.

My point (which you missed) was: publish the algorithm and the
(so-called) public keys, and that problem suddenly vanishes.

Then IGC standard (requiring a DOS program or a WIN32 DLL, or whatever
the next revision of the standard may require) is irrelevant for my
post. It's sad that the IGC standard is so short-sighted, and I would
like to see it changed.

On the other hand, logger manufacturers are probably interested in
having an expiration date for their products, so they can sell new
ones.

Max

[Dave Nadler]

Max, the point is:

Anybody making a logger has to deal with IGC,
if they want to get it "approved".
If "IGC experts" claim that "releasing code
will invalidate approval", well...

PS: Use DOSbox on your PDA for validation ;-)

[Max Kellermann]

Dave Nadler > wrote:
> Anybody making a logger has to deal with IGC,
> if they want to get it "approved".
> If "IGC experts" claim that "releasing code
> will invalidate approval", well...

What, are you serious? Publishing a signature algorithm and the
"public" key will invalidate the IGC logger approval? Is that IGC's
official policy? (Never heard of that rule before) Is that how IGC
thinks cryptography works?

Is that stupidity or willful evil?

> PS: Use DOSbox on your PDA for validation ;-)

*shudder*

[Dave Nadler]

On Wednesday, December 7, 2011 9:53:45 AM UTC-5, Max Kellermann wrote:
> What, are you serious? Publishing a signature algorithm and the
> "public" key will invalidate the IGC logger approval? Is that IGC's
> official policy? (Never heard of that rule before) Is that how IGC
> thinks cryptography works?
>
> Is that stupidity or willful evil?

Max, I didn't say that, I refuted it in the above postings
which you should really read...

[Dave Nadler]

Are you going to enlighten us or just wave your hands ?
You are making contradictory statements above...
Thanks !

[Max Kellermann]

Dave Nadler > wrote:
> Max, I didn't say that, I refuted it in the above postings
> which you should really read...

Your post seemed to suggest that this is an IGC rule, because (1) you
said you have to deal with IGC rules (2) conjunctive sentence that
discusses an IGC expert thinking this would make the approval invalid.

Strictly speaking, your whole post said nothing, especially the second
sentence that was subjunctive and incomplete (missing the main
sentence). That's why I asked for clarification on what you really
mean. Your response doesn't answer my question.

So how is the fact that you need IGC approval relevant for this whole
discussion and for publishing algorithms + public keys? I don't
understand.

Max

[Dave Nadler]

On Wednesday, December 7, 2011 1:57:21 PM UTC-5, Max Kellermann wrote:
> ...I don't understand.

No kidding. Please read the posts above from TNP and my answers.
Carefully.

[Westbender]

Ok, so let me see if I understand this correctly. If the private key
must be held (and protected) within the recorder, then trying to
convert a file that's already outside the recorder would be impossible
since the private key needed for the signature is not accessible. The
real solution would have to be a firmware change in the CAI 10/20/25
itself to enable downloading of an igc format file that is already
signed with the internal private key. It needs to work like the CAI302.

[Dave Nadler]

On Wednesday, December 7, 2011 4:31:15 PM UTC-5, Westbender wrote:
> Ok, so let me see if I understand this correctly. If the private key
> must be held (and protected) within the recorder, then trying to
> convert a file that's already outside the recorder would be impossible
> since the private key needed for the signature is not accessible.

Not if the file has the signature already computed INSIDE THE LOGGER
prior the data is exported from the logger. This is what is supposed
to happen for an IGC-approved logger.

If it is *not* possible, there's something very fishy about the
existing approval.

Hope that clears it up,
Best Regards, Dave

[Westbender]

On Dec 7, 3:43*pm, Dave Nadler > wrote:
> Not if the file has the signature already computed INSIDE THE LOGGER
> prior the data is exported from the logger. This is what is supposed
> to happen for an IGC-approved logger.
>

Doesn't the .cai file have this "signature"?

[Westbender]

I'm thinking the security record in the .cai file must have some kind
of checksum information that no longer applies when the file is
converted to igc. The resulting igc file does have "G" records, but I
take they're not valid because the checksum information doesn't match
any more. Or the "G" records are just a faux signature.

Does anyone know the technical details regarding signatures in cai vs.
the converted igc?

[Dave Nadler]

On Wednesday, December 7, 2011 6:03:29 PM UTC-5, Tim Newport-Peace wrote:
> There is more data in the CAI file than in the IGC file.

Is this additional data (missing from the IGC file) included in the digital signature ?

Why is this additional data not just copied into the IGC file
(into a proprietary sentence) ?

[Dave Nadler]

On Thursday, December 8, 2011 11:16:08 AM UTC-5, Dave wrote:
> > If so, these loggers NEVER met the IGC requirements, correct ?
>
> Correct. These loggers were approved in Jan '96. The first release of
> the "Technical Specification for IGC-approved GNSS Flight Recorders"
> was Oct '97. The approval for these loggers was grandfathered.

The loggers were approved before there was an approval procedure ?

[Marc]

On Dec 8, 1:33*pm, Westbender > wrote:
> All igc files have to abide by the same rules for validating security.
> The checksum logic to build (or validate) the "G" records have to be
> consistent across all manufacturers flight recorders. Otherwise we
> would have a different validation routine for every manufacturer.

There ARE different validation routines for every approved flight
recorder manufacturer. In the case of Cambridge, there are two
different validation routines for the Models 10/20/25 and 302/302A.

> As Dave pointed out, there should be a way to use an existing software
> routine to build the correct "G" records for these files. It shouldn't
> matter whose software it is. They should all come up with the same
> resulting "G" records since that's what they have to generate in order
> to compare for validation purposes.

Unfortunately, that's not the way it works.

> I'm sure the OLC only has one
> validation routine (now that the cai kluge is going away).

Of necessity, they have a number of such validation routines, either
by running the existing DOS programs and DLLs as background processes,
or using specialized manufacturer supplied code.

> The only
> problem associated with this is how do you verify that the igc file
> came from a cai file ...AND... was "untouched". The only way to do
> that is to add the "G" record creation to a single-pass cai-to-igc
> converter....OR....have a website somewhere that allows you to submit
> your cai file and get back an authentic igc file while giving no
> access to the igc file until it is securely signed.

That could be done, but who's going to do it? Software costs time and/
or money to write and support.

> There's got to be someone out there who can step up to save these
> recorders.

Or, of course, one could also come up with an alternative to the OLC
that operates with no validation on an honor system. Whatever the
option, it would still cost time and/or money to come up with a
solution for a 15 year old flight recorder design that hasn't been
manufactured or sold for the better part of a decade.

> I have talked to Cambridge about other software projects (I'm a
> developer). They were certainly willing to listen at that time. Never
> say never...

At which time and to which Cambridge? You do realize that the
Cambridge that exists now is not the same company that designed the
Model 10/20/25 and the 302/302A? To my knowledge, none of the
original employees even work there at this point...

Marc

[Westbender]

On Dec 8, 4:31*pm, Marc > wrote:
> On Dec 8, 1:33*pm, Westbender > wrote:

>At which time and to which Cambridge? You do realize that the
>Cambridge that exists now is not the same company that designed the
>Model 10/20/25 and the 302/302A? To my knowledge, none of the
>original employees even work there at this point...

It was around a year and a half ago regarding the 302 download
utility. I have a solution for a blue-tooth interface and wanted to
see if they were open to enhancing the 302 utility to take better
advantage of it. I offered to do the coding for them as a donation. We
chatted about it, but other priorities got in the way and I never
followed up with them.


>
> There ARE different validation routines for every approved flight
> recorder manufacturer. In the case of Cambridge, there are two
> different validation routines for the Models 10/20/25 and 302/302A.
>

From a pure igc file perspective (not a converted cai file), if it's
true that the different manufacturers all use different methods to
generate (and validate) the "G" records, then we have a non-standard
way of securing igc files. I find that very surprising. I suppose the
reason for that is to prevent a common single method from being
cracked, thus breaking security across the board for all
manufacturers.

Just because the 10/20/25 are 15 years old and they're out of
production doesn't mean they should be written off as viable flight
recorders. There are a lot of them out there. I think it's still worth
it to look for a solution to this problem. Certainly coming up with a
way to sign a log file should be magnitudes simpler than creating an
alternative "OLC" system. From a cost perspective, there's nothing
that rules out charging a small license fee for the new conversion
program that signs the file correctly. There's just no way this can be
all that expensive and time consuming to do. It only requires a
programmer and a little time.

Here's a thought that I'd be willing to try to implement. If someone
were to "wrap" the existing cai to igc conversion program and pass the
resulting igc file (before the user can access it) through an
additional step to create a signature, that should be enough. The
developer of this process can provide a validation DLL to the OLC just
like any other manufacturer or flight computer software company. The
OLC has granted software packages like XCSoar approval. Why not
something like this? One would only have to prove that the process is
reasonably crack-proof. It's not like we need to support world record
attempts and such. We just want to be able to keep these recorders
active on the OLC.

Food for thought.

[Marc]

On Dec 8, 3:19*pm, Westbender > wrote:
> Just because the 10/20/25 are 15 years old and they're out of
> production doesn't mean they should be written off as viable flight
> recorders. There are a lot of them out there. I think it's still worth
> it to look for a solution to this problem. Certainly coming up with a
> way to sign a log file should be magnitudes simpler than creating an
> alternative "OLC" system. From a cost perspective, there's nothing
> that rules out charging a small license fee for the new conversion
> program that signs the file correctly. There's just no way this can be
> all that expensive and time consuming to do. It only requires a
> programmer and a little time.

I'm not suggesting that they should be written off, just indicating
why you shouldn't expect the current Cambridge or OLC to do anything
on their dime.

> Here's a thought that I'd be willing to try to implement. If someone
> were to "wrap" the existing cai to igc conversion program and pass the
> resulting igc file (before the user can access it) through an
> additional step to create a signature, that should be enough. The
> developer of this process can provide a validation DLL to the OLC just
> like any other manufacturer or flight computer software company. The
> OLC has granted software packages like XCSoar approval. Why not
> something like this? One would only have to prove that the process is
> reasonably crack-proof. It's not like we need to support world record
> attempts and such. We just want to be able to keep these recorders
> active on the OLC.

Both validation and conversion are handled by ancient DOS programs.
They could be run using a DOS equivalent under some sort of emulation
or virtualization environment. Should be relatively easy to wrap, as
these things go, several people have done it already...

Marc

[Dave Nadler]

On Thursday, December 8, 2011 4:33:26 PM UTC-5, Westbender wrote:
> All igc files have to abide by the same rules for validating security.

Right.

> The checksum logic to build (or validate) the "G" records have to be
> consistent across all manufacturers flight recorders. Otherwise we
> would have a different validation routine for every manufacturer.

Wrong. We DO have a different validation routine per manufacturer.

> As Dave pointed out, there should be a way to use an existing software
> routine to build the correct "G" records for these files.

No, that is NOT what I said. Again:
IFF all the information used to compute the original signature,
and the original signature are contained in the file, then it
should be possible to VALIDATE the file. It should NOT be possible
to recreate the signature as that requires the private key hidden
in the logger.

Of course, if these loggers don't each have a unique key they
are quite insecure anyway...




> It shouldn't
> matter whose software it is. They should all come up with the same
> resulting "G" records since that's what they have to generate in order
> to compare for validation purposes.

Wrong. See above.

> I'm sure the OLC only has one
> validation routine (now that the cai kluge is going away). The only
> problem associated with this is how do you verify that the igc file
> came from a cai file ...AND... was "untouched". The only way to do
> that is to add the "G" record creation to a single-pass cai-to-igc
> converter....OR....have a website somewhere that allows you to submit
> your cai file and get back an authentic igc file while giving no
> access to the igc file until it is securely signed.

No, No, No....

> There's got to be someone out there who can step up to save these
> recorders.

Certainly not if they are insecure in the first place.

[Westbender]

On Dec 8, 8:26*pm, Dave Nadler > wrote:
> On Thursday, December 8, 2011 4:33:26 PM UTC-5, Westbender wrote:
> > All igc files have to abide by the same rules for validating security.
>
> Right.
>
> > The checksum logic to build (or validate) the "G" records have to be
> > consistent across all manufacturers flight recorders. Otherwise we
> > would have a different validation routine for every manufacturer.
>
> Wrong. We DO have a different validation routine per manufacturer.
>
> > As Dave pointed out, there should be a way to use an existing software
> > routine to build the correct "G" records for these files.
>
> No, that is NOT what I said. Again:
> IFF all the information used to compute the original signature,
> and the original signature are contained in the file, then it
> should be possible to VALIDATE the file. It should NOT be possible
> to recreate the signature as that requires the private key hidden
> in the logger.
>
> Of course, if these loggers don't each have a unique key they
> are quite insecure anyway...
>
> > It shouldn't
> > matter whose software it is. They should all come up with the same
> > resulting "G" records since that's what they have to generate in order
> > to compare for validation purposes.
>
> Wrong. See above.
>
> > I'm sure the OLC only has one
> > validation routine (now that the cai kluge is going away). The only
> > problem associated with this is how do you verify that the igc file
> > came from a cai file ...AND... was "untouched". The only way to do
> > that is to add the "G" record creation to a single-pass cai-to-igc
> > converter....OR....have a website somewhere that allows you to submit
> > your cai file and get back an authentic igc file while giving no
> > access to the igc file until it is securely signed.
>
> No, No, No....
>
> > There's got to be someone out there who can step up to save these
> > recorders.
>
> Certainly not if they are insecure in the first place.

Too late Dave. Someone else already shot everything down. Sorry you
missed out.

[Westbender]

Ok, Thanks to the folks that gave me the motivation to dive further
into this issue. After digging deeper and reaching out again to the
OLC folks, I have gotten some direction from them on how to proceed
with trying to find a solution. I've spent a reasonable amount of time
studying and researching the IGC requirements for digitally signed
flight logs, and I have put together a secure solution in the form of
a windows app and associated validation DLL.

If anyone would like to help me with some testing, please email me
privately. Only folks with 10/20/25 loggers please.

[Max Kellermann]

Westbender > wrote:
> I have put together a secure solution in the form of a windows app
> and associated validation DLL.

Is there a chance you're going to release the source code of that DLL
under a free software license?

(If you think this would harm security, then it's not secure, just
snake oil.)

Max

[Westbender]

On Dec 11, 10:54*am, Max Kellermann > wrote:
> Westbender > wrote:
> > I have put together a secure solution in the form of a windows app
> > and associated validation DLL.
>
> Is there a chance you're going to release the source code of that DLL
> under a free software license?
>
> (If you think this would harm security, then it's not secure, just
> snake oil.)
>
> Max

I haven't gotten that far yet. I don't think there's any reason why
the source code can't be released, although I don't know why that
would be important. All the DLL does is run the hashing algorithm and
decrypt the signature using the public key so they can be compared.
There isn't much to it. Really, the only thing that needs to be secure
is the private key that's used to create the digital signature in the
converter program. The private key is not in any way part of the
validation DLL. By the way, in case you're wondering, this software
uses 1024 bit DSA asymmetric encryption/decryption keys. The hashing
algorithm is my own and uses SHA1.

In my opinion, the most important thing is managing the private/public
key pairs and keeping them in sync. This software has to be stable so
that there is as little chance as possible for problems. If this were
to come to fruition, the slightest problem resulting in technical
support inquiries created by people monkeying around with open source
code will possibly cause the OLC to want to drop support again.
Remember this is for legacy CAI loggers only. There will be no need
for future development since the design and versions of those loggers
are static. Once this software matures, there will be very little need
for updates.

There will have to be some controlling authority to manage and release
new key pairs if the need for them (unlikely crack) ever arose.
Although I can't imagine that anyone would want to spend the effort to
crack a digital signature of this complexity on flight logs for the
OLC. I agree with most people that we should not have to go through
this crap. However since this is what it's going to take to keep these
loggers alive on the OLC, then I'm willing to give this a try.

[Marc]

On Dec 11, 12:59*pm, Westbender > wrote:
> I haven't gotten that far yet. I don't think there's any reason why
> the source code can't be released, although I don't know why that
> would be important. All the DLL does is run the hashing algorithm and
> decrypt the signature using the public key so they can be compared.
> There isn't much to it. Really, the only thing that needs to be secure
> is the private key that's used to create the digital signature in the
> converter program. The private key is not in any way part of the
> validation DLL. By the way, in case you're wondering, this software
> uses 1024 bit DSA asymmetric encryption/decryption keys. The hashing
> algorithm is my own and uses SHA1.

I'm a bit confused as to what you are doing. Are you simply hashing
the contents of the supplied IGC file, appending a new signature, then
providing code to the OLC so they can verify the new signature? How
does the OLC verify that the newly signed IGC file is, in fact, a
valid copy of the CAI flight data file originally downloaded from the
GPS-NAV?

Marc

[ZL]

On 12/11/2011 4:20 PM, Tim Newport-Peace wrote:
>
> The only way I can see for it to be in any way secure is for the
> application to:
>
> Read the .CAI file
> Perform a Validation Check.
> If Validation Passes:
> Create an IGC file
> Digitally sign it as proposed.
> Else Abort.
>
> Otherwise there is no chain of evidence.
>
> For this to be acceptable to IGC (as against OLC), I guess that it would
> need to be a Server-Side application.
>
> Tim Newport-Peace
>
> "Indecision is the Key to Flexibility."

This is exactly what it does. It does not need to be acceptable to igc,
the binary file is still acceptable to them. This is an OLC only fix,
since they can't, or won't, handle the binary file directly.

A server-side application using this code would be more secure, but this
is far better than the PDA files already accepted. If it goes on a
server, why not on the OLC server? They handle zipped igc files, so its
not a binary upload constraint. They handle DOS validation tools
already. Seems weird from out here.

-Dave

[Westbender]

> The only way I can see for it to be in any way secure is for the
> application to:
>
> Read the .CAI file
> Perform a Validation Check.
> If Validation Passes:
> * * * * Create an IGC file
> * * * * Digitally sign it as proposed.
> Else Abort.
>


Bingo

[Westbender]

> This is exactly what it does. It does not need to be acceptable to igc,
> the binary file is still acceptable to them. This is an OLC only fix,
> since they can't, or won't, handle the binary file directly.
>
> A server-side application using this code would be more secure, but this
> is far better than the PDA files already accepted. If it goes on a
> server, why not on the OLC server? They handle zipped igc files, so its
> not a binary upload constraint. They handle DOS validation tools
> already. Seems weird from out here.
>
> -Dave

Dave is correct. The only relevance it has to the IGC is that we're
abiding by their specifications for securing and digitally signing the
resulting .igc file. This is an attempt to create a conversion process
that takes a proven secure .cai file and produces a secure .igc file
from it. This is not a solution for badges, records, real-life
contests, etc. This is an OLC-only proposal. Although lets not get
ahead of ourselves. It's probably unlikely that we can pull this off,
but it's worth a try. It's certainly technically feasible as I already
have a working prototype. The real challenge is getting involvement
from the right people to help us with an attempt to get an approval
from the OLC.

[Marc]

On Dec 11, 6:04*pm, Westbender > wrote:
> > This is exactly what it does. It does not need to be acceptable to igc,
> > the binary file is still acceptable to them. This is an OLC only fix,
> > since they can't, or won't, handle the binary file directly.
>
> > A server-side application using this code would be more secure, but this
> > is far better than the PDA files already accepted. If it goes on a
> > server, why not on the OLC server? They handle zipped igc files, so its
> > not a binary upload constraint. They handle DOS validation tools
> > already. Seems weird from out here.
>
> > -Dave
>
> Dave is correct. The only relevance it has to the IGC is that we're
> abiding by their specifications for securing and digitally signing the
> resulting .igc file. This is an attempt to create a conversion process
> that takes a proven secure .cai file and produces a secure .igc file
> from it. This is not a solution for badges, records, real-life
> contests, etc. This is an OLC-only proposal. Although lets not get
> ahead of ourselves. It's probably unlikely that we can pull this off,
> but it's worth a try. It's certainly technically feasible as I already
> have a working prototype. The real challenge is getting involvement
> from the right people to help us with an attempt to get an approval
> from the OLC.

I''ll be honest, in my opinion, unless the validation, conversion from
the CAI binary file to IGC format, and generation of digital signature
are done as consecutive steps in a secure environment (on a server
belonging to the OLC or a trusted third party), all that is being
created is a nice illusion. The OLC wants a signature to validate,
and they'll get one, even if it doesn't prove anything about the
actual source of the data in the IGC file. I have the same
reservations about accepting as "secure" digitally signed IGC files
produced by PDA/PNA software. Personally, I don't understand why the
OLC even bothers validating the files, it's extra work for them, and
it's not like anyone is winning anything except some bragging rights.
Better that all involved understand that it is possible to produce
fake IGC files, and shun those who are caught doing so.

If you distribute the program to end users, with or without the source
code, there are going to be ways to trick it into applying the
signature to an arbitrarily modified IGC file, such as providing fake
versions of VALI-CAM.exe and CONV-CAM.exe. Plus, of course, the
private key must be present in the program, which means someone with
patience can determine what it is. If the computer and software are
under end-user control, I don't see any easy way to prevent these
sorts of things...

Marc

[Westbender]

> I''ll be honest, in my opinion, unless the validation, conversion from
> the CAI binary file to IGC format, and generation of digital signature
> are done as consecutive steps in a secure environment (on a server
> belonging to the OLC or a trusted third party), all that is being
> created is a nice illusion. The OLC wants a signature to validate,
> and they'll get one, even if it doesn't prove anything about the
> actual source of the data in the IGC file. I have the same
> reservations about accepting as "secure" digitally signed IGC files
> produced by PDA/PNA software. Personally, I don't understand why the
> OLC even bothers validating the files, it's extra work for them, and
> it's not like anyone is winning anything except some bragging rights.
> Better that all involved understand that it is possible to produce
> fake IGC files, and shun those who are caught doing so.
>
> If you distribute the program to end users, with or without the source
> code, there are going to be ways to trick it into applying the
> signature to an arbitrarily modified IGC file, such as providing fake
> versions of VALI-CAM.exe and CONV-CAM.exe. Plus, of course, the
> private key must be present in the program, which means someone with
> patience can determine what it is. If the computer and software are
> under end-user control, I don't see any easy way to prevent these
> sorts of things...
>
> Marc

Marc, are you willing to get involved? Lot's of people have opinions
and are willing to shoot stuff down. Very few of them step up and
offer solutions and help. Are you a software guy? How about it?

I agree that a "black-box" web-service that accepts a cai file and
returns a digitally signed igc file would be the ultimate solution. I
have been considering that as well. The interesting thing is that the
OLC is exactly that. However, they won't do the little bit of work
required to do this conversion. They act like it takes too much time
and effort. I claim otherwise. In a matter of hours, I created a small
app with the original Cambridge programs (VALI-CAM.exe and CONV-
CAM.exe) embedded, which provides a single-pass process for validating
the cai, converting it to igc and digitally signing it. I don't claim
that this solution is 100% crack-proof and maybe someone with enough
hacking talent could do it. I believe the hashing and digital
signature is very secure assuming the private key is protected. I
suppose there's always some yahoo out there that likes a challenge
though.

Folks have to play by the OLC's rules if they want to post their
10/20/25 flight logs there. This is one possible solution that didn't
take much effort. Proving that it's viable and acceptable to the OLC
is another matter. I don't know what their "security threshold" is for
approval. They do accept files from PDA software, so the bar really
isn't that high.

[Marc]

On Dec 11, 9:44*pm, Westbender > wrote:
> Marc, are you willing to get involved? Lot's of people have opinions
> and are willing to shoot stuff down. Very few of them step up and
> offer solutions and help. Are you a software guy? How about it?

I already am involved, how do you think I know about this stuff?

;^)

Marc

[Max Kellermann]

Westbender > wrote:
> I haven't gotten that far yet. I don't think there's any reason why
> the source code can't be released, although I don't know why that
> would be important.

For people who don't run 32 bit Windows on an Intel CPU.

For people who don't to run "untrusted" closed-source software.

Practical example: I want to download and verify the flight from the
Cambridge with my Streak running Android. The Streak has an ARM CPU,
so even if I wanted and even if Windows would run on it, there would
be no chance to use your DLL. None of my computers runs Windows,
anyway.

The majority of devices sold currently have an Intel CPU, and the
majority of devices sold currently don't run Windows.

If you're not convinced that disclosing and freeing the source code is
important, I can elaborate more.

Max

[Max Kellermann]

Marc > wrote:
> I''ll be honest, in my opinion, unless the validation, conversion from
> the CAI binary file to IGC format, and generation of digital signature
> are done as consecutive steps in a secure environment (on a server
> belonging to the OLC or a trusted third party), all that is being
> created is a nice illusion.

You're right by saying it's an illusion, but I strongly disagree that
a server-side service is a viable solution.

What if you don't have internet access?

What if the server is down?

What if the server is commercial (like the OLC), and I object to use
that?

What if the server operator abuses his powers to censor criticism on
his site (like the OLC), and I object to use censorship-promoting
services?

What if I want to attend to a contest that is independent of IGC and
independent of OLC? In the middle of the desert, without any chance
to hook up to the 'net?

What if the server gets hacked, and the server's private key gets
disclosed? This hack will retroactively invalidate all existing
signatures. This can be recovered by re-signing all files by using
the original Cambridge files, but this is a big practical challenge,
maybe practically impossible; does the pilot really have a backup?
Will you get all pilots to resubmit all backups? (Certificate
authorities do get hacked, see DigiNotar and others)

This problem is not something that should put Cambridge owners in a
dependency situation on one entity. This problem can be solved with a
free tool that does not require internet connection, and that does not
require this kind of dependency. If such a solution is possible, it
should be done that way.

If this can technically only be achieved by storing the whole verbatim
Cambridge file (including the verbatim signature; using base64?) in
the IGC file, then be it so. It's not 1995 anymore, and inflating the
IGC files is the lesser evil.

Max

[Max Kellermann]

Max Kellermann > wrote:
> The majority of devices sold currently have an Intel CPU, and the
> majority of devices sold currently don't run Windows.

I mean the majority "don't" have an Intel CPU (but an ARM). It's
too early in the morning in my time zone! ;-)

Max

[Marc]

On Dec 11, 11:11*pm, Max Kellermann > wrote:
> You're right by saying it's an illusion, but I strongly disagree that
> a server-side service is a viable solution.
>
> What if you don't have internet access?
>
> What if the server is down?
>
> What if the server is commercial (like the OLC), and I object to use
> that?

Please note that this thread is entitled "OLC and Cambridge 10/20/25
support ending", and that it is quite hard to use the OLC without at
least occasional access to the internet, and some amount of
willingness to put up with OLC policies.

> This problem is not something that should put Cambridge owners in a
> dependency situation on one entity. *This problem can be solved with a
> free tool that does not require internet connection, and that does not
> require this kind of dependency. *If such a solution is possible, it
> should be done that way.

The owners of every approved flight recorder, so far, are each
dependent on the manufacturer of their flight recorder, nothing is
different here. Validation source code has never been publicly
released for any approved flight recorder, although that might well
change some day. In any case, usable validation source code for the
GPS-NAV can never be released, as it does not use public key
cryptography.

> If this can technically only be achieved by storing the whole verbatim
> Cambridge file (including the verbatim signature; using base64?) in
> the IGC file, then be it so. *It's not 1995 anymore, and inflating the
> IGC files is the lesser evil.

That can be done, and then what? At the other end, you'd need to
extract the embedded CAI file, and run VALI-CAM.exe followed by CONV-
CAM.exe to be certain of getting the valid IGC file. It would be
simpler to submit the original CAI file in the first place...

Marc

[Max Kellermann]

Marc > wrote:
> The owners of every approved flight recorder, so far, are each
> dependent on the manufacturer of their flight recorder, nothing is
> different here.

The difference is that Cambridge cannot revoke my rights to use my
logger, but an online service can do that at any time. I have to
permanently agree to the server's terms of service to use it, while I
don't have to agree to anything to use my logger. This is a huge
difference. Maybe not for you, but I care a lot about such things
that may potentially limit my freedom.

> Validation source code has never been publicly released for any
> approved flight recorder, although that might well change some day.
> In any case, usable validation source code for the GPS-NAV can never
> be released, as it does not use public key cryptography.

Which means that a key that can generate "valid" CAM files is already
disclosed to the public. How will your proposed server-side solution
address that problem? How will your server identify tampered CAM
files?

> That can be done, and then what? At the other end, you'd need to
> extract the embedded CAI file, and run VALI-CAM.exe followed by CONV-
> CAM.exe to be certain of getting the valid IGC file.

I was looking forward to a solution that may include a free VALI-CAM
program which could be embedded in my own software, but sadly that is
a pipe dream. I hope this dream comes true one day for a logger. For
this to come true, pilots should express this wish, which I hereby do
(or, better, I try to convince other pilots of the advantages of free
validation procedures).

> It would be simpler to submit the original CAI file in the first
> place...

The CAI-inside-IGC approach has the advantage that any software may
evaluate the flight without having to implement another (proprietary)
file format. But yes, uploading the verbatim CAI binary file instead
of IGC is another interesting approach that could be considered.
Again, that would require that this proprietary format is made open.

Max

[Westbender]

On Dec 12, 12:59*am, Max Kellermann > wrote:
> Westbender > wrote:
> > I haven't gotten that far yet. I don't think there's any reason why
> > the source code can't be released, although I don't know why that
> > would be important.
>
> For people who don't run 32 bit Windows on an Intel CPU.
>
> For people who don't to run "untrusted" closed-source software.
>
> Practical example: I want to download and verify the flight from the
> Cambridge with my Streak running Android. *The Streak has an ARM CPU,
> so even if I wanted and even if Windows would run on it, there would
> be no chance to use your DLL. *None of my computers runs Windows,
> anyway.
>
> The majority of devices sold currently have an Intel CPU, and the
> majority of devices sold currently don't run Windows.
>
> If you're not convinced that disclosing and freeing the source code is
> important, I can elaborate more.
>
> Max

Downloading a flight from a Cambridge 10/20/25 has nothing to do with
this effort. I am not proposing that, nor am I trying to solution
that. If you're talking about the cai 2 igc conversion process, that
is being done by leveraging the existing vali-cam and conv-cam
utilities from Cambridge. They are currently limited as to what OS
they will run on. I also am not trying to solution any alternatives
for that. I am only trying to provide a solution for 10/20/25 owners
to be able to continue posting their flights on the OLC....period! If
that means it's bound by the same OS limitations that has been in
place up to today for these loggers, then so be it. A limited means is
better than no means. Let's not try to make a mountain out of a mole
hill.

[Westbender]

On Dec 12, 12:59*am, Max Kellermann > wrote:
> Westbender > wrote:
> > I haven't gotten that far yet. I don't think there's any reason why
> > the source code can't be released, although I don't know why that
> > would be important.
>
> For people who don't run 32 bit Windows on an Intel CPU.
>
> For people who don't to run "untrusted" closed-source software.
>
> Practical example: I want to download and verify the flight from the
> Cambridge with my Streak running Android. *The Streak has an ARM CPU,
> so even if I wanted and even if Windows would run on it, there would
> be no chance to use your DLL. *None of my computers runs Windows,
> anyway.
>
> The majority of devices sold currently have an Intel CPU, and the
> majority of devices sold currently don't run Windows.
>
> If you're not convinced that disclosing and freeing the source code is
> important, I can elaborate more.
>
> Max

I'm willing to bet that a vast majority of 10/20/25 owners would be
happy to have a new (free) windows-based utility to enable them to
continue posting their flights on the OLC. Untrusted? Sure, you could
say that. Would a flood of apps built by every Tom, Dick and Harry
from open source be any more trusted? Absolutely not!

[Ramy]

On Dec 11, 8:43*pm, Marc > wrote:
> *Personally, I don't understand why the
> OLC even bothers validating the files, it's extra work for them, and
> it's not like anyone is winning anything except some bragging rights.
> Better that all involved understand that it is possible to produce
> fake IGC files, and shun those who are caught doing so.
>

I think we all agree on that. It is unclear to me why OLC still
insisting on the security record. After all, unsecure loggers such as
PDA are allowed, so it is not like they are protecting logger
manufactures. And the security is obvioulsy an illusion, there are
many ways to fake scores on OLC if someone care so much about their
bragging rights. Flights are scored wrongly all the time, usually
unintentionally. If the OLC team does not realize this, it is time to
pull their heads out of their ass. Problem is, they probably don't
care to follow complains on RAS, so I would expect perhaps the US-OLC
Committee to step up to address OLC issues. The SSA web site is
listing one person in the OLC committee but I haven't seen any OLC
related comments from him.
As for the Cambridge issue, the only pilots I know which were still
downloading flights from model 20 loggers are flying selflaunchers
which can not use PDA generated igc file due to missing ENL record. So
my question is why PDAs do not record ENL, either using the ENL data
from the logger if transmitted, or using the PDA mic?

Ramy

[Max Kellermann]

Westbender > wrote:
> I'm willing to bet that a vast majority of 10/20/25 owners would be
> happy to have a new (free) windows-based utility to enable them to
> continue posting their flights on the OLC.

The vast majority of owners want a solution now, but choosing the best
technical solution often isn't a popularity contest. You would win
that bet, but your bet doesn't matter - Cambridge owners now want a
solution that works now, and today they do not care about the problems
they will face in a few years. Just like in 1996 they didn't care yet
about the problems they face today. I see it as our responsibility
(we = hackers like you and me) to ensure that the next time, the
problem doesn't exist.

> Untrusted? Sure, you could say that. Would a flood of apps built by
> every Tom, Dick and Harry from open source be any more trusted?
> Absolutely not!

That kind of suggestive rhethoric is dull. What does Tom, Dick and
Harry have to do with this?

From your point of view, you are the most trustworthy person in the
world. But that is just your point of view. From my point of view,
you are not, because I don't know you.

From my point of view, all open source developers are more trustworthy
than you, because I can verify that their programs are free of
malware. And I often do.

Max