|
|
|
| Authored by: foulis on Thursday, November 22 2012 @ 08:49 AM EST |
<b>From:</b> Will Poole<br>
<b>Sent:</b> Tuesday, August 06, 2002 6:30PM<br>
<b>To:</b> Brian Valentine; Mike Beckerman<br>
<b>Cc:</b> Jim Allchin<br>
<b>Subject:</b> RE: Sfp api and WM setup</p>
I was not aware and will look into this with Mike asap.</p>
thanks</p>
----Original Message----<br>
<b>From:</b> Brian Valentine<br>
<b>Sent:</b> Tuesday, August 06, 2002 6:18PM<br>
<b>To:</b> Jim Allchin; Will Poole<br>
<b>Subject:</b> FW: Sfp api and WM setup<br>
<b>Importance:</b> High</p>
According to the base guys, the media player found their own hack around WFP and
didn't call the exception process the right way, etc... so when we documented
the called for the compliance decree, we had to take an exception on the way it
done for security reasons. According to Lonny, the player could fix this the
right way - but he said they are getting a lot of resistance from the player
folks. Are you guys aware of this? We have to make some decisions this on SPI
and how to handle this. So it's time critical. I think the right answer is that
the player fixes itself to follow the rules.</p>
<b>From:</b> Lonny McMichael<br>
<b>Sent:</b> Tuesday, August 06, 2002 6:14PM<br>
<b>To:</b> Brian Valentine<br>
<b>Cc:</b> Patty Esack<br>
<b>Subject:</b> FW: Sfp api and WM setup<br>
<b>Importance:</b> High</p>
Brian, here's one of the early threads regarding Windows Media Player's use of
the <b>SfcFileException</b> back-door. The more recent thread was
atty-client privileged, and I've requested that Sue Glueck (the LCA
representative on that thread) forward the thread to you.</p>
Thanks, Lonny</p>
----Original Message----<br>
<b>From:</b> Lonny McMichael<br>
<b>Sent:</b> Tuesday, February 26, 2002 2:14PM<br>
<b>To:</b> Zach Robinson; Scott Harrison<br>
<b>Cc:</b> Marian Trandafir; Bob Fruth; Brett Miller; Erik Odenborg;
Jason Cobb; Jamie Hunter<br>
<b>Subject:</b> RE: Sfp api and WM setup</p>
Hmm. Recalling this <b>fully</b> may be difficult, as it was in 1999
and I purge mail regularly. The little I have in my old SFP</p>
<center>1</p><b>Plaintiff's
Exhibit<br><u>8580</u></b><br>Comes V.
Microsoft</center><br>
<p align=right>MS-CC-RN 000000586859<br>HIGHLY
CONFIDENTIAL</p>
<hr>
<br>
folder <b>written in 1999:</b><br>
===<br>
<tt>*Doesn't seem to work on RC2, work-around is to delete catalog file.
Same package works fine on RC3? Work around is to delete our catalog
files.<br>
*Doesn't seem to work on various builds. Work around is to tell test we only
support IDW builds.</tt><br>
Above seem to reflect the fact that WFP was unstable in its early days--no
surprise, and not germane to this discussion.</p>
<tt>*Doesn't version check on file installs, just overwrite. This forces
us to have version checking logic in the package host
applications.</tt><br>
This is very much by-design. Basing copy decisions on a per-file version number
simply does not work. The versioning should be done at the package (i.e.,
component) level, and once the decision is made that a given package should be
installed, then all files associated therewith must be installed to ensure
package integrity (and maintain environment in which said package was
tested/verified, etc.). This is not an argument against using exception
packages, it's an indication that you are installing your files presently under
broken assumptions.</p>
<tt>*Beyond specs and faqs, seems to be little dev support for this. Since
it's kind of flakey right now, that's pretty critical to us not getting bogged
down debugging what should be trivial issues.</tt><br>
This reflects the fact that exception packages were meant to be few and far
between, and our (naive) approach was that if we made it hard to do an exception
package, then fewer groups would attempt to do so. Instead, we found that they
plowed right on ahead and either (a) circumvented WFP altogether (as you've
done) or (b) constructed a bogus exception package, got signing authority from
WinSE team, and proceeded to screw us by distributing packages that we could
neither administer nor upgrade.</p>
<tt>*At this point it requires us to use setupapi.dll to install our
files. This means error recovery and reboot state issues and non-admin issues
are out of our control.</tt><br>
Please expand on this point. What do you mean by "error recovery"? If
an error occurs during setupapi queue committal, then we rollback the entire
queue, so that the resultant on-disk state is left unaltered.</p>
Also, could you elaborate on what "reboot state issues" you
encountered? When setupapi is dealing with a signed package, it will not request
a reboot unless absolutely required (e.g., if the existing file is in-use, and
we must copy a new one over). To deal with this, you could ensure that the
file(s) you're replacing aren't in use prior to committing the file
queue.</p>
I also remember that JasonC and I spent time with a couple of guys from the WMP
team (sorry, don't remember their names) to assist them in developing a better
algorithm for upgrading CD-ROM class filter drivers such that reboots were
avoided if at all possible. (This was a result of JimAll encountering a reboot
request when installing WMP) The last I heard, that work was never incorporated
into any WMP update.</p>
Finally, w.r.t. "non-admin issues", this is simple. Non-admins should
not be able to replace global in-box components. Period. If you guys are trying
to address that, you're going to run up against the security wall (if you
haven't already).</p.
===</p>
I believe that what was happening was that we found Exception Packages were not
working reliably. We got Andrew Ritz to look into our package, nothing was
amiss, I believe Kirt Debique pulled in some security guy to triple-check that
the test cert/catalog were being installed correctly, and everything checked out
there too. I had high pressure on me to get this working, and it simply
wasn't.</p>
As far as specific bugs, I think the issue was with regards to not calling
SfcFileException for the files, so they were being replaced when they should not
have been. I believe I followed this one up with Andrew as well (perhaps someone
else?) and they assured me that should not be a problem, whereas I found that my
own implementation calling SFE fixed the issue.</p>
Thankfully enough there is no third option on the table: <b>we are not and
will not be talking about documenting this</b>, as it wouldn't make any
sense to do so.</p>
What the discussion thus appears to be about is WTF we did this. Am I correct? I
was told I had two goals:<br>
<ol><li>Make this work</li>
<li>Don't reboot</li></ol></p>
<center>2</center>
<p align=right>MS-CC-RN 000000586860<br>HIGHLY
CONFIDENTIAL</p>
<hr>
<br>
#1 wasn't being met at the time, and as far as #2, we have special-casing and
other beautiful things you can do when you implement your own INF installer that
drastically minimizes reboots. I have been told that I will be shot if I cause a
machine to reboot, so I don't want to do so.<br>
I'd like to know what "beautiful things" you're doing that setupapi
wasn't. Since setupapi make all attempts at avoiding reboots, I'm inclined to
believe that "beautiful" may equate to "slimy hacks", but
I'll reserve judgement until I see your response.</p>
These are my recollections offhand. If there are further issues/questions,
perhaps we would be better suited to meet so we can have Q/A rather than
drawn-out exchanges of...Exchange mail.</p>
<blockquote>----Original Message----<br>
<b>From:</b> Scott Harrison<br>
<b>Sent:</b> Wednesday, February 20, 2002 4:56PM<br>
<b>To:</b> Zach Robinson<br>
<b>Cc:</b> Marian Trandafir; Bob Furth; Lonny McMichael; Brett
Miller<br>
<b>Subject:</b> Sfp api and WM setup</p>
Zach can you describe the bugs we hit with the existing sfp implementation that
prompted us to use the SFC dll api directly.</p>
I know the lack of file versioning is one issue are there others?</p>
As background for those not in the loop the current plans of the wm team
are</p>
1) ask for and get approval for WM setup to use this undocumented sfpapi since
it is a Windows Security API (we do this with drm for example)</p>
2) change code to not use undocumented security/wfp API if exception is not
granted. (unknown what the work is involved to do this)</p>
Documenting the SFP API is <b><u>NOT</u></b> part of
this plan and is <b><u>NOT</u></b> acceptable to anyone
involved here.</blockquote></p>
<br>
<center>3</center>
<p align=right>MS-CC-RN 000000586861<br>HIGHLY
CONFIDENTIAL</p>
[ Reply to This | Parent | # ]
|
|
|
|
|
