c4c-dev team mailing list archive

[KI7MT <ki7mt@xxxxxxxxx>]

Hello All,

I've been thinking about this authentication thing a little bit.

There appears to be two use case situations:

[1] PC's that are pre-built and pre-imaged with C4C
[2] ISO Installation by the user


Situation [1]

>From a server content delivery standpoint, an easy way to administer
this would be through the use of SSH Key pairs (private & public). Each
system built and delivered to the receiver ( the person getting the
computer ), would get a unique key pair generated off a MB serial
number, chipset serial number or something that would be unique on every
machine. Those key pairs will determine if they that system has access
to the media or not. This is how we all access servers through SSH for
web-hosting, VPS server administration, even our launchpad code work.

Those keys would be installed on the system before delivery, and added
to the server's authorized Key list. *That can be your control point*.
If they re-install the system, loose their key or whatever, they would
be required to request a new set, and thus agreeing to the EULA again
before they are sent to them.

This of course would restrict access to the server via SSH to Key access
only, which is a good thing anyway. Debian has this implemented for all
their access for us Maintainers.


Situation [2]

This is much the same as a user loosing their key pair and having to
request a new set. The end user, if they want to use the Download
facility (for media ) would have to request a Key pair. When they do,
they must agree to the EULA. To get the initially, they would have to
request them via email, web-interface or whatever.


Conclusions

While it's not perfect, it does provide a high level of containment, and
it's used throughout the Internet as a stand means of access. All this
can easily be shell scripted.

You could take this one step further, and add passwords to the Keys as
well, which I would advise. Those PW's should never be given back out.
If they forget it, to bad, so sad, request a new key pair.

There is only one issue with this, Zsync does not work over SSH, Rsync
does, SCP does, Curl does.

Zsync is more efficient, no question about that, but rsync is a *very
good* file transfer protocol. It's used to backup servers all over the
web, every day. That, coupled with 7Z compression, should work quite
well. Not to mention, binary data (music files, video's etc) do not
compress, so we're pretty much stuck with whatever the file sizes are
anyway.

Rsync commands are simple: rsync -avr pointA/ pointB/

Over SSH one simply adds the User and IP Addy to the string. Point A and
B can be any combination of IP addresses, Network Addresses, or Local
Disk paths.

The only thing you'd have to do really, is add the key pairs to the
servers auth list when issuing new pairs. Would be a good idea to keep a
log of the data and what not, but that's pretty easy.


Thoughts ??


best regards,

Greg


On 05/18/2015 03:34 PM, Israel wrote:
> Hi again,
> zenity is a gtk application, and AFAIK there is no real Qt equivalent..
> but I have only used KDE a handful of times, and the same goes for LXQt.
> 
> So, if we want to make an installer we would need to do a few different
> things.
> a) make Qt and GTK installers
> b) use a different toolkit (I am very familiar with FLTK using c++)
> c) look into Qt dialog programs (do they exist, how good are they?)
> 
> A bash script is going to be the quickest and easiest way for me to
> sketch out a program we can test, and use.
> 
> @Greg do you know any programming languages?
> 
> I don't have much experience using curl/rsync so my vote is for zsync,
> as it is used for ISO downloads
> 
> I think as a further precaution we need to look into some sort of
> passkey type thing for use with the binary files, in order to further
> protect things, or some other way of verifying that the zsynced files
> are going solely to a c4c machine (or someone installing c4c-music or
> whatever)
> I don't have any real suggestions for this right now... but just the
> thought that we should do this
> 
> 
> On 05/18/2015 12:12 PM, KI7MT wrote:
>> HI Eric,
>>
>> You don't need the QT Opensource Installer .. that's for QT application
>> development, which we are not doing at this point; it was just an
>> example of lengthy downloads and accepting the EULA.
>>
>> Everything we need QT wise will be provided by the base Installation
>> ISO. We don't need to be concerned about those packages.
>>
>> best regards,
>>
>> Greg.
>>
>>
>>
>> On 05/18/2015 11:07 AM, Eric Bradshaw wrote:
>>> Guys,
>>>
>>> Again, no expertise - but, my thought is we may want to use the QT Open
>>> Source installer simply because Lubuntu is transitioning to LXQt
>>> (supposedly) by 15.10 - so maybe we'd be prepared? Apologies if one
>>> would have nothing to do with the other.
>>>
>>> Eric
>>>
>>> On 05/18/2015 09:14 AM, KI7MT wrote:
>>>> Hi Israel, All,
>>>>
>>>> Yes, zsync, rsync or even curl could do that job easily. A simple shell
>>>> script could do what is needed here.
>>>>
>>>> If you have ever used MSYS/MinGW, this is exactly how their installer
>>>> works for pulling packages to install form the SF server. The same for
>>>> the QT Open Source installer, and it pull a is HUGE amount of data at
>>>> install.
>>>>
>>>>
>>>> best regards,
>>>>
>>>> Greg.
>>>>
>>>> On 05/18/2015 07:43 AM, Israel wrote:
>>>>
> ...
>