Re: Idea for structure of Apt-Get
(Responding to both Javier Fernández Garcia and Brett Viren)
(Security)
Bittorrent is similarly secure to the existing debian mirror system.
In a Bittorrent system, you'd be distributing .torrent files from trusted
debian mirrors - torrent files contain cryptographic hashes for each block of
the data. The bittorrent protocol is already error correcting using the
cryptographic hashes - any bad data injected would be recognized and
discarded (and the recipient may decide to not accept data from that sender
again for the current session).
There's actually a potential security gain: the set of trusted mirrors could
be much smaller. On the other hand, aren't debian packages gpg signed anyway
- making the whole security discussion redundant?
(Granularity)
The granularity issue and the latency issue are linked pretty closely. If you
tried to implement this with existing bittorrent clients you'd run into
exactly the problem that you mention - needing to have a separate instance of
the client open for each .deb involved.
It would be possible with the current protocol to have one big .torrent file
for the entire release, similar to the package list you download when you say
"apt-get update", and then to only download the individual files that you
need - the existing BitTornado client does this. I don't know if this would
work for debian - it actually might.
On Saturday 19 March 2005 06:54 pm, Javier Fernández Garcia wrote:
> Hello.
>
> This thought looks pretty interesting. I wonder if I could trust p2p...
> I'll explain myself:
>
> what would happen if someone changed the source code of a chunk of an
> application, I mean, I trust the servers from where I download the
> packages, but can I trust any user that offer me a chunk?
On Saturday 19 March 2005 06:55 pm, Brett Viren wrote:
> One more:
>
> Nat Tuck <nat@ferrus.net> writes:
> > The biggest issues here are
> > A.) unexpected bandwidth usage.
> > B.) horrible latency
>
> C.) granularity
>
> Please correct me if this is wrong, but must not a torrent pre defined
> to be a single file (or set of files)? If so, one would need to
> decide at what granularity to build the torrents: one per .deb, one
> per category, one per section.
>
> If the .torrents are fine grained it means leaving many BT clients
> open. OTOH, if they are made more inclusive, it means using more
> disk/bandwidth than really required.
>
> -Brett.
Reply to: