All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Randy.Dunlap" <rddunlap@osdlab.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: Network protocol for linux-hotplug.
Date: Mon, 08 Oct 2001 14:22:00 +0000	[thread overview]
Message-ID: <marc-linux-hotplug-100255122013514@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-100250374523386@msgid-missing>

Dmitri wrote:
> 
> Quoting Stamatis Mitrofanis <ewstam@softhome.net>:
> 
> > It had occurred to me that it might be a good idea to make things such
> > that unsatisfied hotplug requests are forwarded through the network to
> > certain database servers.
> 
> > This automatic-downloading system must be very small, very uniform and
> > very simple to implement. Questions that need answers:
> 
> > - What protocol do we use for communication of the user system with the
> > server system? (must be well-known and standard)
> 
> http:// and nothing else. This is because of firewalls and proxies
> that are capable of handling it. Other protocols/ports are often
> blocked from leaving intranets. Also, all http:// infrastructure is
> already available and widely deployed, allowing easy mirroring.
> 
> > - How do we organize scripts and programs to do the job?
> 
> wget http://www.kernel.org/cgi-bin/getdriver?bus=usb&pid=0x1234&vid=0x5678
> tar xzvf usb_0x1234_0x5678.tar.gz
> cd usb_0x1234_0x5678 && make && make install
> 
> > - What will be the formats for drivers downloaded from the net?
> 
> likely, tarballs - but .rpm or .deb is also OK, as long as the originator
> of the request asked for them, *and* as long as they are available. This
> means that the script has to know how to fall back to the tarball.
> 
> > - <insert your question here>
> 
> Add mandatory signatures to all packages, and mandatory checking of
> said signatures vs. hardcoded list of identities (public keys).
> This means that only holders of these keys can publish drivers.
> Otherwise this will be insecure, to put it mildly :-)

I must strongly agree with Dmitri's last statement.
Without some form of security checking, this scheme is a huge
open hole for danger.

But like Keith said, source code is the only form that
scales and works on all types of platforms, at least right now.

~Randy

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

  parent reply	other threads:[~2001-10-08 14:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-08  0:05 Network protocol for linux-hotplug Stamatis Mitrofanis
2001-10-08  1:50 ` Keith Owens
2001-10-08  1:57 ` Dmitri
2001-10-08 14:22 ` Randy.Dunlap [this message]
2001-10-08 19:01 ` Tim Jansen

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=marc-linux-hotplug-100255122013514@msgid-missing \
    --to=rddunlap@osdlab.org \
    --cc=linux-hotplug@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.