sipb / chiron Goto Github PK

Some kind of rate-limit to reduce people's tendency to play with chiron seems desirable. It's not clear how exactly this should work, since I think pasting a bunch of tickets on -c debathena is pretty common. Some possibilities:

• limit only certain fetchers/matchers (Debathena #xxx is probably pretty safe, but XXX Airport is more likely to get played with)
• limit only certain classes (I think people tend to behave better on -c debathena than -c sipb)
• limit messages, not tickets -- bulk lookups tend to be one zephyr, and playing (at least when annoying) tends to be spread out (though I'm less sure this is a good enough distinguisher)

To some degree, Chiron-#18 is a substitute for this.

CVEs have identifiers, Launchpad/Debbugs/Bugzilla has bugs, Github has issues or pull requests (depending on number!), Scripts FAQ has entries, the Pokédex has Pokémon, MIT has classes, the Bible has verses, XKCD has comics, Unicode has characters, airports have codes, and Assassin/SCIENCE/Debothena Test have…whatever the hell. So really the only thing that calls them tickets is Trac. We should stop calling everything a ticket and let matchers specify the appropriate language.

When requested, Chiron should stop replying to any tickets on a class for five minutes or something.

"Debathena #276" caused chiron to crash with:

2014-10-08 20:59:10.234736: -c sipb -i "debathena": [email protected] ->
  -> Found ticket: Debathena, 276
Traceback (most recent call last):
  File "/afs/sipb.mit.edu/project/chiron/chiron/main.py", line 149, in <module>
    run_with_args(match_engine)
  File "/afs/sipb.mit.edu/project/chiron/chiron/main.py", line 145, in run_with_args
    chiron_protocol.main(match_engine, options)
  File "/afs/sipb.mit.edu/project/chiron/chiron/chiron_zephyr.py", line 136, in main
    ZephyrMessage.main(match_engine, options)
  File "/afs/sipb.mit.edu/project/chiron/chiron/chiron_zephyr.py", line 133, in main
    match_engine.process(msg)
  File "/afs/sipb.mit.edu/project/chiron/chiron/chiron.py", line 354, in process
    messages = format_tickets(self.last_seen, msg, tickets)
  File "/afs/sipb.mit.edu/project/chiron/chiron/chiron.py", line 370, in format_tickets
    message = '%s ticket %s: %s' % (tracker, ticket, t)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 7: ordinal not in range(128)

That bug name is "Shouldn’t accept Kerberos passwords for local users without [email protected] in .k5login"; I assume the single quote in shouldn't was the problem.

We have doctests for the types of fetchers -- Github, Trac, etc. -- but we should add some tests that ensure that each individual fetcher is still ~working (eg, the URL hasn't changed).

It would be handy if athrun chiron chiron --subs=my-secret-class (or athrun chiron chiron.py --subs=~/.chiron.subs) resulted in a chiron with a reasonable set of matchers running, subbed to some private class. As is, if you want to run chiron on some private class, it requires editing some python yourself.

scripts / personal / achernya + 2014-08-28 12:02 [team-rocket.mit.edu / Alexander Chernyakhovsky]
Scripts #355
-> scripts / personal / daemon/chiron (auto) + 2014-08-28 12:02 [cats-whiskers.mit.edu / http://scripts.mit.edu/trac/ticket/355]
Scripts ticket 355: Unable to identify ticket 355
But the expected response would have been "Move stella web client into the scripts locker" as the ticket exists.

Maybe if we had Zulip support, we could get this thing running at not-MIT.

I want to be able to look up a bunch of debathena tickets by doing zwrite daemon/chiron.mit.edu -i debathena and just putting numbers in the body. This works on -c adehnert-test, but not in personals.

It's a little annoying that debothena occasionally dies and nobody restarts it until somebody gets highly confused about why it isn't replying.

(Suggested by glasgall.)

Zulip personals lead to a last_seen key of ('whats', u'stark', [{u'full_name': u'Alex Dehnert', u'domain': u'randomfish.org', u'email': u'[email protected]', u'short_name': u'adehnert+hunt', u'id': 4735}, {u'domain': u'randomfish.org', u'short_name': u'chiron-bot', u'email': u'[email protected]', u'full_name': u'Chiron', u'id': 4902}]), which crashes because that list isn't hashable. .cls() for zulip messages probably needs to be revisited.

There's a noticeable core to Debothena, plus some ad-hoc fetchers and bunch of matcher/fetcher definitions. We should split the core from the more specialized stuff, so it's easy for somebody else to run a debothena instance that doesn't conflict with the main one.

We now have a couple fetchers (RHBZ and the Bible, at least) that return several lines of text. These work fine when they're the only thing being fetched, but it's a bit ugly when several things are fetched at once, because they're isn't much visual separation between them. We should make this prettier.

https://cve.mitre.org/cve/identifiers/syntaxchange.html

I keep breaking things. Maybe tests will make me do that less.

debothena should be able to look up a DSA number, such as DSA-2516-1. Looks like the easiest way to find that is at http://security-tracker.debian.org/tracker/DSA-2516-1. The canonical site appears to be http://www.debian.org/security/2012/dsa-2516, but to look it up there, you need to know what year it was.

Right now, to detect personals we check if "debothena" appears in the recipient. We should probably support running a Debothena instance as daemon/scripts-bugs.mit.edu or the like. (The dev.py script turns out to mostly work for development, because replies to non-personals go to the recipient of the original zephyr, not just no-recipient/empty/'*'. If you're running dev.py with your tickets and zephyring it from your barnowl to test, this works fine.)

I should get permission to use some license from all contributors, and then indicate the current license.

"Debothena\n#20" should still be detected as a ticket, even though there's a linebreak instead of a space.

etherpad.mit.edu has a Trac at https://etherpad.scripts.mit.edu/trac/. We should support it.

When a personal zephyr (or possibly just a personal zephyr with no other recipient) doesn't mention any tickets, it's probably a sign that somebody is asking for a bugtracker that isn't supported or is typoing or something. Rather than leaving people wondering whether Debothena is being slow, we should report an error (possibly listing the supported trackers).

Matcher entries currently look like (fetcher, matchers, cond). However, the matchers is always [build_matcher(regexp, re.I)], and the cond is always lambda m: True or lambda m: cls in m.cls. This should just be (fetcher, regexp, cond) or so to allow for more useful introspection of the matchers. (See also #4, which this is basically part of, and #11, which this is probably a prereq for.)

People mention XKCD's by number a lot.

The SIPB whats command allows expanding acronyms. Chiron should too.

At the moment, Linerva is using the Debathena Trac. That shouldn't stop Debothena from replying to "Linerva" tickets, though, so alias Debathena to Linerva.

It's kinda stupid that requesting "Debothena #11" on -c debathena will display Debathena #11 and Debothena #11. If a fetcher is specified, we shouldn't use the default fetcher for a class.

Fixing this probably requires fixing Debothena-#4, so "default fetcher for a class" is actually meaningful.

It sounds kinda stupid to say "Debathena ticket 123: debathena-cluster-ghudson-thing should divert /usr/sbin/useradd.debathena-orig"....

It looks like some RFCs use different markup from others, leading to the RFC fetcher to fail to extract the title.

For example, https://datatracker.ietf.org/doc/html/rfc3986 uses

<span class="h1">Uniform Resource Identifier (URI): Generic Syntax</span>  

and is successfully matched by

title = xml.xpath('string(//span[@class="h1"])')

but e.g., https://datatracker.ietf.org/doc/html/rfc9110 uses

<h1 id="title">HTTP Semantics</h1>

and is not matched.

It's possible that adding

if not title:
    title = xml.xpath('string(//h1[@id="title"])')

in https://github.com/sipb/chiron/blob/master/chiron_bot/fetchers.py fetch_rfc might help, but I didn't test this.

If I zephyr debothena in personals with one ticket and (say) geofft does with the same ticket, debothena should reply to both of us, despite them both being on class message.

It's not totally obvious what to do if I zephyr CC geofft and zephyr CC broder whether it should reply to both. Possibly -c message should just not do the five minute thing. (See also Debothena-#12, which would at least make this bug more understandable.)