On Wed, 14 Mar 2018, Dave Mielke wrote: > It's just that network security wasn't understood very well back > then so the higher management was putting too much trust in the people who > had > that job at the time.
My boss at a former job had to put a PC under his desk. That PC would establish an outbound ssh connection to a few remote employees with port forwarding so we could effectively connect back into the company's network. This backdoor was the only way to do it as the IT people would simply refuse to provide any incoming access, not even with VPN boxes. And the ssh connection would use the https port of course, as anything else was blocked. This arrangement lasted for a couple years and went undetected all that time. > I set up the login profile for their account with a prompt which stated that > I > believe Bible reading to be good for people so would they please first read > one > chapter from the Bible and then enter into the prompt which chapter it was. > The > prompt stated that this was all on the honour system, and that I was assuming > them to be honourable people who'd answer truthfully. Did they ever log in? > >Oh absolutely. We do have too many functions that can be bound already. > > Well ... we could start using long presses. The problem with this, however, > is > that some braille devices don't support them. What I mean is that pressing a > key on some of them immediately sends the release so we can't tell how long > it > was pressed for. So long presses are useful for devices that support them, > but > we can't use them as a general solution. Maybe that could be useful if someone wants to move between two different types of prompts. But I think that for now, simply providing the ability to change the current prompt matching should actually cover most advanced use cases. > >Well, obviously that default regexp is an internal detail. It is just > >the default value when the config file option is not provided. This way > >the implementation is kept simple with only one method. > > I prefer if-then-else, i.e. if it's set then use it else use the current > code. > There are two reasons for this. One is that we need fallback code, anyway, in > the case that autoconf says that we can't use regular expressions. The other > is > that it prevents surprises from creeping into the default case. Fair enough. > >Indeed. But like the initial proposer suggested, the content from all > >backref substitutions would have to be filtered so regexp special > >characters are turned into literals.. > > I missed that one. In any case, I don't think that the comlexity of creating > a > dynamic regular expression would really give us all that much extra. Maybe not. That could be extended eventually if need be. For example: prompt_match = |<regexp>| # that's a direct match prompt_match = |<regexp1>|<regexp2>| # that's the ultimate match No need to implement the later initially. Nicolas _______________________________________________ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: [email protected] For general information, go to: http://brltty.com/mailman/listinfo/brltty
