If you control the proxy and have it secured, local tampering should not be an issue. Unless something has changed with the way MS distributes its updates, I understood them to have Authenticode built in. This should maintain the integrity of the update through installation, shouldn't it?
As for end users running WindowsUpdate, they do not have the necessary permissions to run the updates (or install software of any kind). I take care of running the updates manually myself or I deploy them via SMS (this is my preferred and most-oft used method). Luckily we really do not have to deal with customized applications.
Granted, not everyone works within these same parameters which can limit the appeal of caching the updates.
-Jeff
-----Original Message-----
From: Melvyn Sopacua [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 12, 2002 07:35 AM
To: [EMAIL PROTECTED]
Subject: [sambar] tweaks {09}
Allthough I agree on the bandwidth saver, it is also a security risk.
As far as I know, MS doesn't provide md5 hashes or anything similar, so the risk of somebody fiddling with the files in transit or in the proxy's cache are there (remote - but we're still talkin' about system upgrades here).
Further more - in an organisation, with multiple users, you really want to deny access to windowsupdate, simply because you'll pay the price, when everybody updates 'as they should', and some custom app stops working.
We had that, with on of the XML fixes in IE and Doubleclick Dart was broken for 5 days.
Now - in this case - it wasn't a very big problem, since it was me who suffered and I alerted the people who had to work with Dart daily, to not install
that update.
If your organisation relies on MS based software, and have made extensions to it, you may be in for a big surprise. Typically you or your IT department would stay in touch with Technet, and test the upgrade and it's uninstall feature (if possible!) before applying anything.
Then make the approved update available on the network and mail everyone the location, or use login scripts/remote logins - you get the point.
Jeff Adams said at 12:58 12-6-2002:
>This is true for any caching proxy server that can cache more than just
>HTML files. It works on the same principal - a client requests a file,
>the proxy checks to see if the file is already in the cache, if it is in
>the cache it makes sure the file is not stale, if it is not in the cache
>it attempts to download the file and put it in the cache, and then the
>file is returned to the client. Subsequent requests for the file are then
>drawn directly from the cached file until its entry becomes stale at which
>time it is updated.
------------------------------------------------------- To unsubscribe please go to http://www.sambar.ch/list/
