Actually, it seems that this WOULD allow open source drivers. The monitor vendor can publish the hardware interface without compromising the security of the system. And open source drivers merely pipe the encrypted data right on through to the display device. Because the decryption is done on the end, and the OS drivers are only in the middle, there is nothing to hide from developers.
My understanding is that there are TWO problems, one dated December 1, and one dated December 13.
From BUGTRAQ in a message by Iván Arce (http://www.core-sdi.com):
As noted in the advisories ( http://www.core-sdi.com/advisories/buffer%20over flow%20ing.htm and http://www.cert.org/advisories/CA-99-15-RSAREF2.ht ml ) there are TWO buffer overflows. The first is in the SSH distributed file rsaglue.c the second is in the rsa.c file that is part of the RSAREF2 distribution.
Slashdot Mirror
Actually, it seems that this WOULD allow open source drivers. The monitor vendor can publish the hardware interface without compromising the security of the system. And open source drivers merely pipe the encrypted data right on through to the display device. Because the decryption is done on the end, and the OS drivers are only in the middle, there is nothing to hide from developers.
vic
My understanding is that there are TWO problems, one dated December 1, and one dated December 13.
r flow%20ing.htm t ml )
From BUGTRAQ in a message by Iván Arce (http://www.core-sdi.com):
As noted in the advisories (
http://www.core-sdi.com/advisories/buffer%20ove
and http://www.cert.org/advisories/CA-99-15-RSAREF2.h
there are TWO buffer overflows. The first is in the SSH distributed file rsaglue.c the second is in the rsa.c file that is part of the RSAREF2 distribution.