c4c-dev team mailing list archive

[Israel <israel@xxxxxxxxxx>]

Hi,
I think this is brilliant!
This thoroughly covers every thing possible, adds more security, adds
strict compliance with the ambiguous 'for c4c use only' and makes me
feel generally a lot better about the whole deal.
Please do this!

On 05/19/2015 02:04 AM, KI7MT wrote:
> 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:
>>>>>
>> ...
>>


-- 
Regards

-Israel
ToriOS Team