LWN: Comments on "Study: Attacks on package managers"

Study: Attacks on package managers

mdz@debian.org — Mon, 21 Jul 2008 09:35:44 +0000

This is typically due to a broken transparent proxy, or similar network anomaly, between you
and your chosen package mirror.

Debian security

justincappos — Thu, 17 Jul 2008 17:20:47 +0000

(Disclosure: I'm an author of the study)

I agree with you that using a security repository significantly reduces the vulnerability to
attack. This doesn't protect against the "endless data" attack we describe that can be used
by a mirror to crash clients, but this is not as big of a threat as compromising the client.
(Does Debian need to contact so many mirrors by default?)

There are several other minor issues that remain and may impact Debian users that we didn't
see discussed here. First, there is no authentication that you are talking with the security
repo, so a MITM attacker can still launch attacks by masquerading as the repo. HTTPS with
correct certificate checking would prevent this, hence the HTTPS ("Bad research at its best")
suggestion. :)

Second if the security repo fails or is not contactable from a client (non-transitive
connectivity, etc.) then the mirrors can attack clients by replaying content from the security
repo.

Third, clients who use netselect-apt, etc. should be aware that they are likely to remove the
security repo from their list of mirrors and thus become vulnerable.

In general we found that Debian's practice of using a security repository is effective in
protecting their users from replay / freeze attacks in the majority of cases for users with
default configurations.

There is another issue with Debian that we didn't bring up on the web pages because we felt
there was already too much loosely connected content. We briefly looked at the developer
update process and if I understand correctly from reading the documentation any developer can
update any package (they are encouraged not to except in extreme situations but have the
ability to). Furthermore, if I understand correctly there are thousands of keys in the
developer database so really this means that a compromise of any key allows an attacker to
upload any package. Also there are keys as short as 768 bits and as old as 1993. I'm not a
crypto expert so I don't really know how to quantify risk, but both of those numbers trigger a
mental alarm. Anyways, I was hoping that you could also clarify / correct / confirm any of
this information as well.

Thanks,
Justin Cappos

How to fix it

justincappos — Thu, 17 Jul 2008 16:48:57 +0000

There is an additional problem with BitTorrent or other P2P solutions that hasn't been
mentioned in the discussion here.   When you download the current version of a package, you
are commonly doing so because you are upgrading an old version.   So when downloading a
package from an untrusted party (like a mirror) you disclose that you are running outdated
software to that party.   This is obviously bad because they may be able to root you, etc.
Using something like BitTorrent increases the effect because now a much larger group of people
with a lower barrier to entry are aware of you requesting a package.

I don't think this is a good trade-off given the current status quo.

Deficiencies wrt. CentOS

justincappos — Thu, 17 Jul 2008 16:42:55 +0000

I've posted a few corrections on the original blog entry. I'll post here as well.

Hello, I'm one of the authors of the study. I wanted to first of all thank you for
commenting on our research. One of the major benefits we hoped would come from making this
public is that the Linux community would become more aware and interested in fixing the
problems we point out.

I also wanted to respond to several of the issues you brought up in your blog post. First, I
appreciate you pointing out that many distributions check to see if their mirrors are current
and try to remove mirrors that are not. We under-emphasized this in the webpage and other
documents because we did not view this as a mechanism used to detect a malicious party (we
thought the intent was to detect negligent administrators and broken scripts). As I'm sure
you and the savvy reader are aware, it is possible for a web server to serve different content
to different users. We examined our web request logs from our CentOS mirror and I believe we
can identify the "checking bot" IP addresses. If we were malicious, we could serve "good"
content to your checking bot and "malicious" content to other users. I would be happy to
provide what I believe to be the IPs used to check if a mirror is current to you offline for
verification / rebuttal. However, since you view this information as important to the
security of your users, I will not list the information here.

Additionally, I wanted to mention that we found significant security problems with Fedora's
MirrorManager (our FAQ talks about how it can be used to target attacks). However, other
redirectors we looked at (like Download Redirector for OpenSUSE) do improve security in a
similar manner to what you describe. I was wondering if we could talk more offline about how
your mirror list redirection works so we can discuss the potential for abuse?

I also wondered if you might want to look in detail at the other attacks page of the web site
and the technical report which mentions detailed information about flaws in YUM. We would be
happy to discuss the feasibility of attacks that target these issues with you. However, I
will point out one attack that is extremely simple that I hope illustrates there is a real
danger to your users. If I control a mirror and you attempt to retrieve a file from my
mirror, I can return an endless stream of data which (on YUM) will fill the disk and crash the
client system (stopping logging, corrupt databases, etc.). This is obviously a real threat
to all of your users regardless of any mirror redirection strategies you perform.

Anyways, we thank you for taking a look at our research and hope to hear more rebuttal /
confirmation in the future.

Thanks,
Justin Cappos

How to fix it

i3839 — Thu, 17 Jul 2008 14:41:45 +0000

I was more thinking about distro's multicasting package updates and everyone being able to
pick them up. Sending a package update ten times a day for ten days means almost everyone has
the chance to pick it up. Uploading a file a hundred times instead of once per user uses much
less bandwidth if you've more than a few hundred users. Bandwidth usage can be controlled on
the client side by choosing how many streams are read simultaneously.

Throw in a traditional client-server thing to retrieve lost packets or missed updates, and to
enable people with crappy ISPs or routers which don't support multicast, and you've a complete
solution.

Of course multicast has its downsides and troubles, so you'd want to use Source Specific
Multicast, and IGMPv3 support is needed for that. No idea how well (home/ISP) routers do that
though.

Study: Attacks on package managers

hickinbottoms — Thu, 17 Jul 2008 08:08:35 +0000

No, they're not signed. This means the SHA1/MD5 checks only protect you from corruption during
the download (or subsequently on disk, before the package has been built).

You can prove this yourself - you can modify the downloaded package and regenerate those
hashes with a "ebuild ... digest" command, so there's no secret to it.

Portage is, I believe, quite vulnerable to compromised mirrors at present. I believe the
groundwork to GPG-signing (not sure if that covers the package only, or whether it includes
the metadata) has been done some time ago, but it's not progressed to the point where that's
utilised yet.

Deficiencies wrt. CentOS

dag- — Thu, 17 Jul 2008 07:54:58 +0000

The study (and especially the way it is being advertised) is seriously lacking any insight in how yum works (on CentOS). The impact of 'being in the mirrorlist' is really reduced by a number of things and makes the motives of the author(s) of the paper somewhat questionable. (Attention grabbing ?)

We have blogged about this:

http://dag.wieers.com/blog/package-manager-vulnerability-study-flawed

http://www.hughesjr.com/content/view/22/1/

as appeared on Planet CentOS.

How to fix it

dirtyepic — Thu, 17 Jul 2008 05:02:43 +0000

in many cases in the time it takes the BT client to contact the tracker, receive the seed/peer
data, and then establish connections to each of these seed/peers, you could have downloaded
the file directly several times over.  and you never get high transfer rates right off the bat
with BT.  It usually takes a few minutes to get up to a decent speed.

Study: Attacks on package managers

MattPerry — Wed, 16 Jul 2008 18:17:06 +0000

Today I'm getting this error:

GPG error: http://security.ubuntu.com hardy-security Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>Failed to fetch http://us.archive.ubuntu.com/ubuntu/dists/hardy-updates/main/binary-i386/Packages.bz2 Hash Sum mismatch
Some index files failed to download, they have been ignored, or old ones used instead.

If I try to move ahead and installed I get a bold warning that packages can't be authenticated. No suggestions are provided on how to fix the problem. I don't know what I can do except back up my files and reinstall Ubuntu.

How to fix it

bronson — Wed, 16 Jul 2008 17:48:42 +0000

You might have missed this line in my post?

> Any decent bittorrent client will allow you to download just the files that you want and
ignore everything else.

Surely package signing already solves this?

tzafrir — Wed, 16 Jul 2008 17:04:54 +0000

I would like the CDs to contain signed repositories as well.

A valid mirror and an up-to-date mirror are not necessarily the same thing.

Study: Attacks on package managers

epa — Wed, 16 Jul 2008 14:49:27 +0000

Checking the signature is a good thing and I'm not blaming that at all. I am kvetching about the corrupted mirror site existing in the first place. Removing the signature check, obviously, would not improve things. Better error reporting of 'the download failed and the file was truncated' before even attempting the signature check would be helpful, but not essential.

What would be good would be failover handling in the package manager so you didn't need to see that message at all.

Yes. Some kind of client library that automatically handles selecting an upstream server (or more than one, if the download is to be parallelized), checks for data consistency, and restarts or switches servers if the consistency check fails. Bittorrent is one example of a protocol that handles all this, with the added bonus that nodes can share data between each other (as when two machines on the same network both need to update), and that setting up a traditional mirror site using cron jobs and perl scripts is not necessary (just start up the Bittorrent program and tell it how much bandwidth and disk space to use). Some kind of intelligent http frontend would also do the job. Of course you still need to check package signatures after the download has completed successfully.

Why not torrent

epa — Wed, 16 Jul 2008 14:43:08 +0000

I think you answered your own argument: "If it's faster for you, switch mirror."

The point is that users should not have to care about switching mirrors, and (with somewhat
less importance) administrators should not have to care about setting up mirrors and fixing
the various things that can go wrong with them.  Bittorrent is a more complex protocol, but it
is often simpler to use and maintain.  Let the computer do the hard work of figuring out which
site is the nearest and which site has which data.

(I have two Fedora machines on my local network; I could spend disk space and bandwidth
setting up a full mirror but it would be a hassle and download more than I need.  An
alternative is to set up a caching http proxy - but if Bittorrent were used, the machines
would just share the downloaded data automatically.)

It need not necessarily use uplink capacity for the end users.  A leeching Bittorrent client
would be fine for downloading package updates.  I proposed setting up Bittorrent servers
instead of traditional mirror sites - such a server would be a regular Bittorrent node
configured to participate in the package torrents.  Since the server is just there to provide
speeded-up downloads to the users, it can run in generous mode where it will happily provide
data to leeching clients.

Distribution of torrent metadata is indeed a single point of failure.  But so is distributing
a list of mirror sites.  Whatever update method you use, you must start with a single point
somewhere.

How to fix it

epa — Wed, 16 Jul 2008 14:29:38 +0000

Makes you wonder why Bittorrent isn't built on top of UDP?

(Indeed, HTTP GET requests might as well have been be UDP instead of TCP... but that is a
discussion for another day.)

Study: Attacks on package managers

motk — Wed, 16 Jul 2008 00:44:27 +0000

Bittorrent is not a hammer, and not everything is a nail.

How to fix it

motk — Wed, 16 Jul 2008 00:39:14 +0000

Bittorrent uses a ridiculous amount of bandwidth, which is not always Cheap.

Surely package signing already solves this?

njs — Tue, 15 Jul 2008 22:11:48 +0000

One could sign packages in such a way that a replay attack was impossible... assuming that the
client has an accurate clock.

Have a root-level signature re-issued each day over the entire repository, that also includes
the date that it is generated. When talking to a mirror, you can check this root file, and if
it's more than a day or two old, that's a bad mirror and should be ignored. (This also
catches mirrors that are merely stale, which can be a problem sometimes for entirely
non-malicious reasons...) Because the date is signed, the mirror can't pretend to be
up-to-date.

Of course, the signature has to also cover the packages in the repository or it's no use -- a
malicious mirror could serve up a fresh root cert and stale packages, and verifying a
signature made in the naive way over the entire repository would be prohibitively expensive.
(Heck, *generating* such a signature would be prohibitively expensive...) But one could create
a tree of signatures to mitigate this -- the root signs a list of package/version/hash, and
then you just have to download the root, the list of package versions (which you usually
download anyway), and the actual packages you want...

If clients don't have accurate clocks, you could instead put the current root signature on a
single centralized server run by a trusted party (i.e. the distribution itself), and have
everyone fetch it directly; this would be reasonable scalable, since the central box would
only have to serve one few-hundred-byte file instead of being a full mirror.

Not that I expect anyone to do this, but it's fun to think about.

How to fix it

drag — Tue, 15 Jul 2008 18:51:14 +0000

I know it sounds stupid, but are you sure that they are throttling bittorrent?

I seen that Comcast had a investigation on them and all that, but for most cases I think that
it's because of bad bandwidth management on the part of end users is what is causing most
'throttling'.

For example.. At my house I use Cox Cable for Internet. For a long long time I was able to run
bittorrent quite well, but after some changes they made I started running into big issues with
losing packets and huge increases in latency of my network connection. I was only able to get
a third or a forth of the speed of the downloads that I used to get, and this was after a
'network upgrade'. And upload speeds were very poor since other peers were getting
disconnected.

At first blush it seemed very obvious that this was due to some sort of throttling or network
performance shaping on the part of Cox. But in fact it wasn't.

----------------------------------

The deal is, if I understand it correctly, is that Bittorrent is a TCP oriented network
protocol. That is when you send a packet or at least initiate a data transfer you have to have
'ack' packets acknowledge the connection. TCP is connection-oriented protocol.

Home-style network connections are hugely asymmetrical. The download speed vastly outperforms
the upload speeds.

So Bittorrent does upload and download simultanously. As these ISPs increase their download
speeds dramatically they do little to increase their upload speeds.

So with BT the upload becomes a huge bottleneck since even if you rarely saturate the download
it's very very likely that you saturate the upload.

And what happens then is you end up having this huge queue of uploaded packets. Among those
packets being stuck in router limbo are those TCP ack packets, and they don't make it back up
to their destination in time you start having disconnects and all sorts of nasty network
performance problems.

I found that the controls offered by bittorrent clients were very inadequate. This is due to
the fact that there are probably multiple BT clients running at the same time as well as other
network traffic.

So the solution is to have quality assurance rules on your home's router. You can't control
what is being sent to you, but you can have control over the priority of packets leaving your
network. So you have to throttle the ports your using for bittorrent _yourself_ and then give
very high priority to ack packets. Usually your going to have to limit your BT traffic to
80-90% of maximum network bandwidth to get the best performance.

There is a 'wondershaper' set of scripts that can do this, but I found that a modified setup
of that designed for Shoreline firewall/router is the best.

Now my bittorrent downloads are at least 4-5 times as fast as they used to be and I have no
network latency problems.

--------------------------------

So I figure if your experiencing not only slow BT downloads, but huge increases in ping
latency and some limited packet loss then it's not your ISP's fault (except for the
excessively asymmetrical nature of their network). It's your's and your router needs to be
configured to do quality assurance.

Of course if your ISP is actually doing throttling then none of this will help you. Hopefully
you can find another company to go through.

Study: Attacks on package managers

nix — Tue, 15 Jul 2008 18:49:44 +0000

`X' days doesn't work for any fixed value of X. A better check is to check 
that the package date is not much older than the last time you downloaded 
a set of updates which should have included that package (`much' 
introduced to allow time for the package to be uploaded, inter-mirror 
propagation delays, et al).

Downside: this means that after Debian's ftpmasters sit on a package for 
five hundred years they have to get it re-signed before putting it into 
the repo ;) and I'm not sure what implications it has for 
automatically-promoted repositories such as Debian testing: perhaps the 
Date header should be updated, and the signing repeated, by the (trusted) 
software with a silly name which does the promotion (I can't remember that 
name right now, it always drops out of my head). If attackers take *that* 
over, we're all dead anyway.

(sorry for the jab at ftpmasters gone, I couldn't resist ;} )

Bittorrent and small files

nix — Tue, 15 Jul 2008 18:45:59 +0000

Say rather that it doesn't work well with small transfers. My impression 
is that it has very slow start, so for transfers taking less than a few 
minutes, ordinary FTP is going to be noticeably faster.

Kind of weak

salimma — Tue, 15 Jul 2008 15:35:23 +0000

There is a 'yum-fastestmirror' plugin, so if you know the target computer is using it, you can
set up a mirror a small number of hops away and have a good chance of being preselected.
Signing and dating the package list is still the safest solution.

How to fix it

salimma — Tue, 15 Jul 2008 15:30:03 +0000

Multicast would be useful for a sysadmin wanting to update multiple computers all at once, but
otherwise, data still has to be transmitted multiple times.

One solution to this problem

jmm — Tue, 15 Jul 2008 12:22:17 +0000

security.debian.org isn't a single machine, but a round-robin setup of several hosts
administrated by Debian. Last time someone published the stats they were serving ~ 30 MB/s
(which was two days after the last DSA being published, I suppose the peaks are higher)

Study: Attacks on package managers

job — Tue, 15 Jul 2008 12:07:45 +0000

No, it is not.

The system of signatures just prevented you from downloading data from a "misbehaving node"
(i.e. corrupted mirror), and you blame the system?

The mirroring IS handled automatically, AND you are protected from bad data. What would be
good would be failover handling in the package manager so you didn't need to see that message
at all.

It would also be desirable to protect from the attack described in the article, perhaps using
timestamped and signed package indexes?

Why not torrent

job — Tue, 15 Jul 2008 11:56:24 +0000

I can think of a few reasons. Bittorrent is more complex (which would make the install program
larger, and might not fit on a netboot ram image). It is slower. (If it's faster for you,
switch mirror.) It uses uplink capacity for the end users (which some may have to pay for).
Distribution of torrent metadata is a single point of failure.

So in short, it's not robust, it's slow, and it's complicated.

You make it sound like more modern equals better, which should be obvious it is not true.
Otherwise we would not use a web browser when we have 3D games. Different uses, different
protocols.

Study: Attacks on package managers

job — Tue, 15 Jul 2008 11:46:22 +0000

Are all the ebuilds cryptographically signed now? Last time I checked they were not. So the
reason you needn't worry about the attacks described in the article is that the verifications
aren't there in the first place.

Study: Attacks on package managers

Zenith — Tue, 15 Jul 2008 11:17:55 +0000

Quoting rgmoore further up in the discussion:

Someone on Slashdot pointed out a much nastier potential attack. The process is simple: 1. Set up a mirror. 2. Wait for the distro you're mirroring to send out a security update for a package with a remotely exploitable hole. 3. Root the box of everybody who starts to download the updated package. The mirror can look completely legitimate, because it just passively harvests the IDs of vulnerable computers. You probably want to pass off the job of rooting vulnerable computers to a separate botnet to keep your mirror looking squeaky clean.

So yes, a sort of loophole, but not one you can do much about I would think, besides from the whole "trusted mirrors only" scheme mentioned here in the discussion.

Study: Attacks on package managers

tzafrir — Tue, 15 Jul 2008 11:01:00 +0000

This seems to be a high level of paranoia.

apt-tor, anybody?

Study: Attacks on package managers

nhippi — Tue, 15 Jul 2008 10:18:55 +0000

To put it more plainly:

The attacker cannot use a malicious mirror inject old content against security.debian.org,
since security.debian.org isn't mirrored by third parties.

Testing users could become vulnerable. Mitigating against this would be relatively easy to
implement, as the Signed "Release" file already has A "Date" field. - Just check that it isn't
older than X days. As a added bonus, users will start noticing if their mirror has problems
getting updates.

One option the attacker has is transparent proxies, but then again you are in big trouble
anyway (mmm.. cookies..) if a cracker manages to root your ISP's transparent proxy.

Study: Attacks on package managers

epa — Tue, 15 Jul 2008 09:45:28 +0000

The existence of flaky, corrupted mirror sites is another argument in favour of dropping
old-style mirrors and using Bittorrent or some other protocol that handles the mirroring
automatically and is robust against misbehaving nodes.

Study: Attacks on package managers

epa — Tue, 15 Jul 2008 09:43:34 +0000

That is the wrong approach.  You are suggesting there should be verification so that only
trustworthy people (by some measure) can set up a mirror site.  But it will always be possible
for bad guys to slip through the net.  Even the US nuclear weapons programme, with the
strictest possible vetting of participants, contained spies.

And even a well-meaning mirror site can be taken over by an attacker.

Better to make sure the update system is secure so that even with total control of one or more
mirrors an attacker cannot push out bad packages or cause a denial of service for more than a
few minutes.

Bittorrent and small files

epa — Tue, 15 Jul 2008 09:38:06 +0000

What makes you say that Bittorrent does not work well with small files?

Nastier attack

tzafrir — Tue, 15 Jul 2008 09:18:57 +0000

 ...
Alternative (3)
"Root" a whole bunch of NAT routers.

Study: Attacks on package managers

jond — Tue, 15 Jul 2008 08:50:22 +0000

> It doesn't inspire confidence because I'm not a cryptography expert,
> nor do I desire to be one.  As an end user, all I see is an error 
> that I do not understand.  I > don't know why the signature is invalid
> and the error doesn't give me any guidance on what > the significance 
> is nor how to correct it.

I think I agree with you here that the UI side needs work.

> It's using TCP, not UDP, to download the data.  Shouldn't TCP should 
> ensure that I'm getting the correct data?

TCP would protect you against the data being corrupted in transit from the mirror to yourself.
This looks like corruption at the mirror end or (in the case of a bad transparent proxy) stale
data being served up from a cache that doesn't correspond to the package index.

How to fix it

zeridon — Tue, 15 Jul 2008 08:12:27 +0000

Hmm the points said are a bit interesting but untill now everyone forgets that there is
ibiblio and it's sibling Osprey & Permaseed

Basically with that soft they can implement a mirror and BT with seeds directly from the
storrage and on the big pipe.

Last month it was prety usefull 2-3 hours delay from the oficial eclipse release and pushing
hard for the torrents. It made some diffference. The server wasn't so bogged down, and as
eclipse is just sw nobody kills the torrent so we have more seeds :)

Study: Attacks on package managers

MattPerry — Tue, 15 Jul 2008 07:02:23 +0000

> Sometimes, however, this error indicates a "problem" such as not
> bothering to run update for a few weeks and the key has expired.

Are the keys really being regenerated that quickly?  What is the reason for doing that rather
than keeping a key for a long time?

I wonder if that might have something to do with my problem.  I usually don't update my
servers unless I see a post on the security-announce lists indicating that there's an update
for a package that I use.  I can sometimes go for a month or two (or more) before running
apt-get update.  The Ubuntu system that I was attempting to upgrade today was last powered on
sometime in May.

> How will you identify a real security issue in the noise?

I agree.  Right now it seems like "the boy who cried wolf."

Study: Attacks on package managers

MattPerry — Tue, 15 Jul 2008 06:44:59 +0000

> And why doesn't it inspire confidence?  The invalid signature protected
> you from a corrupt download (my guess is that these are usually truncated
> or partially transferred files).

It doesn't inspire confidence because I'm not a cryptography expert, nor do I desire to be
one.  As an end user, all I see is an error that I do not understand.  I don't know why the
signature is invalid and the error doesn't give me any guidance on what the significance is
nor how to correct it.  I know that signed packages and package lists are supposed to protect
me, which is why I sit up and take notice when I see the error.

The best that I've been able to do in this situation is to try the update again and hope the
error goes away.  Usually the error will not happen when I update the package list a second
time.  Occasionally, the error will persist no matter how many times I update and I just try
again later.  That is what happened with Ubuntu today. I ran the "check updates" from the
update manager five times over about 15 minutes and I continued to receive the same error.  If
I try the updates tomorrow, I expect that it will be fine.

It's using TCP, not UDP, to download the data.  Shouldn't TCP should ensure that I'm getting
the correct data?  I wouldn't expect for the transfer to be corrupt several times in a row.  I
could understand if I only saw this error once, but I see it often enough that I don't think a
corrupted download is the problem.  I also see it with Debian and Ubuntu, so it's not
something restricted to one distribution.

Study: Attacks on package managers

jamesh — Tue, 15 Jul 2008 06:35:20 +0000

Occasionally it also indicates a badly behaved almost-transparent proxy sitting between you
and the mirror.

Study: Attacks on package managers

k8to — Tue, 15 Jul 2008 06:29:08 +0000

The reason it doesn't inspire confidence is that this error occurs during normal operation.

Sometime this error indicates a problem of grabbing an inconsistent set of files from a
round-robin type situation.  Yes, the system has saved me from data corruption, theoretically.
Realistically, it is an embarassment that these inconsistencies are encounterable in normal
configurations.  For example, chosing a host such as http.us.debian.org will often result in
data inconsistency during updates.  Why is this advertised as a viable mirror selection if it
does not work reliably?

Sometimes, however, this error indicates a "problem" such as not bothering to run update for a
few weeks and the key has expired.  Once this error indicated that the key had expired before
the new key was even made available, and so the web of trust simply did not extend from one
administration key to the next.  Every user of debian testing encountered this during one
transition.

Perhaps you begin to see the problem?  This thing pops up all the time to suggest a problem
which is not caused by incorectly signed or unsigned files.  How will you identify a real
security issue in the noise?

Study: Attacks on package managers

afalko — Tue, 15 Jul 2008 05:55:31 +0000

All files downloaded from Gentoo have SHA1 and SHA256 sum associated with them. If a file does
not match the file the developer was using, the user will receive a digest error and the
package manger will not continue. Does any one see any loopholes with this scheme?