c4c-dev team mailing list archive

[Eric Bradshaw <ericbradshaw@xxxxxxxxxxxxxxxxxxxxxxxx>]

Guys,

This sounds wonderful, I guess I just want to make sure it's very uncomplicated for the end users. I apologize for my own ignorance, but I believe I would know much less than most about how exactly this all would work and while you all can hopefully walk me through step-by-step I wouldn't be want to put the recipient of our software and/or a C4C computer through what I'd be willing to do. I guess what I'm trying to say is I'd like to above all else make it very easy for the end-user. Like there is a well-defined, maybe even pretty text box in which to type in one code (we deliver with the computer) and from then on they only need their password.

Eric
--
Thank You,
God Bless You,
Computers4Christians
http://Computers4Christians.org/

KI7MT <ki7mt@xxxxxxxxx> 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:
>>>>>
>> ...
>> 
>
>-- 
>Mailing list: https://launchpad.net/~c4c-dev
>Post to     : c4c-dev@xxxxxxxxxxxxxxxxxxx
>Unsubscribe : https://launchpad.net/~c4c-dev
>More help   : https://help.launchpad.net/ListHelp