Nicolas Williams wrote: > On Fri, Mar 07, 2008 at 02:54:04PM -0600, Brian Cameron wrote: >>> If the answer is yes, then that needs to be fixed. I'm guessing >>> __wildly__ that it will be easier to make all the a11y infrastructure >>> part of the trusted path. >> Yes, if it is a requirement to ensure that this sort of information >> can not be manipulated, then it would be necessary to call the >> text-to-speech and braille display engines directly from the >> dialog. >> >> I don't think this means that we need to include "all of the a11y >> infrastructure". It just means that we need to include those > > "all ... needed by the screen lock program"
:) >> components needed to translate text to speech and braille display >> output. >> >> This doesn't necessary mean that we need orca, we could call the >> lower level interfaces directly. This could probably be done >> without using at-spi-registryd at all, if we wanted. > > This is, effectively, a parallel a11y architecture for the trusted path. > If that's easier, sure. It's not complete, just complete enough for the > screen lock program. Right. > Will there be other trusted path consumers of a11y? Obviously there is the login program. Currently GDM 2.20 takes the "whole a11y infrastructure" approach you suggested above. GDM allows you to hit hotkeys to start the magnifier, GOK, or orca to meet a11y needs. However, GDM is not the default login program, and a11y is disabled in GDM by default configuration. GDM is provided so that users with a11y needs can switch to a login program that can be configured for their needs. So this probably means we either don't support both Trusted Path and accessible login, or the whole a11y infrastructure, orca, and GOK are all a part of Trusted Path. I am not sure what our official take on this would be. However, GDM is being rewritten and it is unlikely it will use the same approach. It will probably use an approach more similar to what I suggest for the lock screen, embedding functionality into the login dialogs. That said, the login screen is a bit more complicated than the lock screen dialog, so I think some further thought will need to go into figuring out how to achieve necessary support. Since the dialogs are more complicated, it might really be necessary to use orca, for example. If we decide it makes sense for GDM to manage lock screen, as I suggested in my earlier email, then both graphical login and lock screen would likely use the same techniques for providing a11y, I would think. Aside from login, there is gksu. This is currently needed to support some gnome-system-tools, to allow users to enter the root password to get temporary authority to make certain changes to configuration. However, I understand Visual Panels is coming along and will replace gnome-system-tools, so I think gksu is going away. I'm assuming the VisualPanels team will deal with this problem in a more elegant, RBAC sort of fashion. However, we would probably need to discuss with the VisualPanels team to find out their plans. Aside from this, there are various other programs that ask for passwords, like Evolution, Thunderbird, pidgin, rhythmbox plugins for accessing certain music servers, etc. I am not sure if these programs also have Trusted Path requirements. If so, this is probably more complicated than dealing with the login/lockscreen issues. You can also enter passwords into web pages in firefox, though I have no idea how this could ever be made a part of a Trusted Path. Lastly, people seem to keep talking about how great it would be to integrate PolicyKit into Solaris. If we decide to support it, and it's ability to enter the root password to gain temporary authorities, then I guess this would also be a concern. Though, I am guessing it's also very possibly that PolicyKit is just not appropriate for Solaris use. I'm not sure about this. I don't think there are other programs that interact with passwords that have a11y requirements, aside from, perhaps, people who enter passwords into the terminal program when they run commands like rlogin, ssh, telnet, su, etc. Brian
