[three]Bean
Kerberized fedmsg? Probably not.
Feb 25, 2014 | categories: fedmsg, kerberos, fedora View CommentsLast week, someone contacted me about deploying fedmsg in a kerberos-enabled environment. They wanted to know if they could re-used their krb infrastructure to determine the authenticity of messages. I'm writing this blog post to help me think it through.
First, how fedmsg works
fedmsg doesn't encrypt its communications at all. Messages are either signed using X509 cert/key pairs and verified against against a Certificate Authority cert or signed and verified with GPG keys. Those keys/certs (as of now) need to be pre-shared.
Anyone can read the bus at any point. Anyone can write to "the bus" at any point. Only some messages are trusted. Read more in the fedmsg.crypto docs.
How I think Kerberos works
(... but I'm probably wrong. Have mercy on me).
Kerberos has two central servers that are used to manage trust between clients and servers:
- The Authentication Server
- The Ticket Granting Server
When a client wants to connect to a server...
- It first contacts the Authentication Server. The Authentication
Server responds with two things:
- A "Client <-> Ticket-Granting Server" session key that is encrypted with the client's secret key.
- A "Ticket Granting" Ticket that is encrypted with the Ticket Granting server's secret key.
- The client then does two things:
- The client decrypts the first part (the session key) which it can then use to contact the ticket granting server (it sends an "Authenticator"; it has a session with it now).
- It sends the second part -- the encrypted Ticket Granting Ticket -- to the Ticket Granting server plus the ID of the service it ultimately wants to connect to.
- The Ticket Granting Server then does two things:
- The Ticket Granting server decrypts the Ticket Granting Ticket (with its own secret key)
- It also uses the session key to decrypt the Authenticator.
- Now the Ticket Granting Server is assured that the client is who they
say they are. The Ticket Granting server then does two more things:
- The Ticket Granting Server sends a "Client <-> The Service It Wanted To Connect To" ticket back to the client which is encrypted with The Service It Wanted To Connect To's secret key.
- It also sends a session key for the client <-> server session back to the client.
- Dutifully, the client sends this new ticket to the server with which it ultimately wants to be in a authenticated relationship.
- That server then decrypts all this. It increments a timestamp and re-encrypts it with their new session key. It sends this back to the client.
It looks like when you issue kinit on a machine, that completes step 1. Steps 2-6 are carried out independantly by programs.
Kerberized fedmsg?
The advantage of pulling off a kerberized fedmsg would be that you wouldn't have to set up a separate public key infrastructure just for fedmsg -- you could re-use your kerberos infrastructure. You wouldn't have to generate a CA cert. You wouldn't have to generate certs for each sending service, sign them with the CA cert, and distribute them, manage them...
Is it possible?
Any fedmsg publishing process would have to first assume that the Ticket Granting Ticket is already set up via kinit. What happens next? Usually that TGT is used to request another ticket specifically for communication between the requesting program and another specific service. fedmsg doesn't work that way... Messages are published to anyone/everyone -- an unspecifed set of recipients. It is confusing because the client/server relationship is all twisted.
In step 2, there is no "target service ID" to request.
In step 4, there is no "target service" with a secret key to encrypt anything for.
Even if we faked something out with a 'virtual service' with its on secret key, to whom would the fedmsg publisher send the encrypted ticket in step 5?
The prospects don't look good for a kerberized fedmsg, but I'm open to ideas if you have them. Hit me up in #fedora-apps on freenode or on the messaging-sig if you want to talk more about it.
UPDATE - 2014-02-25, Simo Sorce tells me that kx509 is a thing that could be used to acquire a short-lived certificate as long as you have a TGT. Apparently it needs some work first, though.
A Release Engineering Dashboard?
Aug 30, 2013 | categories: releng, fedmsg, fedora, datagrepper View CommentsMessing around, I came up with a read-only dashboard for Fedora Release Engineering. You can check it out live on threebean.org.
Right now all it does is try to show the status of the compose process which runs once a day for rawhide and the "branched" pre-release (that's F20 right now). If any one of the components of that process (say, the pungify part) is happening right now, it'll tell you that and have it show up in yellow in stead of blue. If the compose hasn't happened in over 20 hours, that text will show up in gray to indicate that it is "stale" or "out of date" (those words might be too strong, but whatever).
The point of this post is to ask for feedback -- should this thing do anything more? If so, then what? Should we make it live under fedoraproject.org?
(details: It's just HTML, CSS, and js and it makes its queries against datagrepper)
New fedora-ask freenode channel (with a bot)
Aug 29, 2013 | categories: askbot, askfedora, fedmsg, fedora View CommentsIf you're in to Ask Fedora, you may want to hop on to freenode and join the new #fedora-ask channel. There's a bot there echoing just the Ask Fedora activity from fedmsg. You could use it, say, to respond more quickly to questions or to stay abrest of new trending problems.
Fedora Badges Launch
Aug 28, 2013 | categories: fedmsg, fedora, badges View CommentsWe launched the new Fedora Badges webapp two weeks ago at Flock, the Fedora Contributor's Conference. It went over really well; the success was kind of stunning.
If you haven't yet, check out the site. The gist is that that frontend web interface is fed by a backend "badge awarder" which sits watching the fedmsg bus. As community members go about contributing to Fedora and interacting with infrastructure systems, they trigger the publication of new fedmsg messages. Upon receiving those messages, the badge awarder then makes a number of comparisons to determine if the person in question should receive this or that badge.
Since the launch, we've noticed an uptick on the fedmsg bus; there has been a definite increase in community activity in certain corners. Just check out the Fedora Tagger votes.
To generate the above chart, I wrote a little tool which you can find here. It uses the datagrepper API, about which I've written before.
Writing that gave us the crazy idea to add datagrepper stats to a zodbot command. Check out this IRC log from #fedora-apps:
threebean | .quote BOD monthly zodbot | BOD, bodhi -13.31% over the month preceding this one zodbot | ▄▅▆▂▁▂▄▃▄▃▁▂▄▃▃█▅▆▁▄▃▃▂▂▆▄▃▄▂▃▃▅▂▁▃▄▃▅▃▂▄▅▄▂▁▁▁▆▅▄ ⤆ over month zodbot | ↑ 21:01 UTC 07/28 ↑ 21:01 UTC 08/27
FWIW, zodbot also got a .badges FAS_USER command now, too:
threebean | .badges ralph zodbot | ralph has unlocked 36 Fedora Badges
Lots of people have asked if they can embed their badges on their own blog or on the wiki or frontend app doesn't provide the tools directly, but we do allow you to export your badges to Mozilla's Open Badges Backpack and they provide some tools for embedding your badges elsewhere.
On our badges app, click the Export Badges button on your profile, login via Mozilla's "Persona" with your FASUSERNAME@fedoraproject.org email address, and create custom badge displays there.
Ricky Elrod whipped up this pretty sweet mediawiki plugin but there is some debate about where we should start centering user profiles. It raises an interesting point, though, that up to this point we have not had nice person-centric view of the Fedora Community before (it has always been package-centric or update-centric or something else..)
(There are still bugs to fix in the stack, but...) The big projects now are to 1) refine badge ideas and to 2) produce art for new badges.
We have an issue tracker just for new badge ideas, but take a look at this report in particular. It lists proposals which have everything they need (an idea, a name, some code to make it real) except for badge art. Can you put something together? Take a look at mizmo's design scheme for badges to get started.
Shout outs (in order of appearance) are due to rossdylan for laying the groundwork last summer, to oddshocks for lifting the web frontend to go-time status, to jenneh for UI mockups and the original badge designs, to mizmo for the badge design scheme and countless badge designs, to adamw for the badge idea submission process and for triaging the avalanche, to ryanlerch and decause for art, to those who filed new badge ideas on the issue tracker and anyone else in #fedora-apps I may have missed.
Some of us from #fedora-apps are going to be presenting on Mozilla's Open Badges Community call on September 11th. Feel free to call in and join us there if you want to talk Fedora Badges.
Lastly, I've got to apologize if I've been slow to respond or too short in my manner with anyone the past few weeks... my TODO list deficit has just gone through the roof.
Querying all package history from the command line
Jul 16, 2013 | categories: pkgwat, fedmsg, datanommer, fedora, datagrepper View CommentsAfter my last post on querying datagrepper, I wrote it into my pkgwat tool as the second-coolest subcommand: $ pkgwat history PKGNAME:
$ sudo yum -y install pkgwat $ pkgwat history firefox +------------+------------------------------------------------+---------------------+ | date | event | link | +------------+------------------------------------------------+---------------------+ | 2013/07/15 | stransky commented on bodhi update firefox-22. | http://ur1.ca/enmvg | | 2013/07/15 | suren commented on bodhi update firefox-22.0-1 | http://ur1.ca/enmvg | | 2013/07/10 | stransky's firefox-21.0-1.fc17 untagged from f | http://ur1.ca/eauo1 | | 2013/07/10 | xhorak's firefox-21.0-4.fc19 tagged into trash | http://ur1.ca/ea995 | | 2013/07/10 | xhorak's firefox-21.0-4.fc18 tagged into trash | http://ur1.ca/ea995 | | 2013/07/05 | stransky's firefox-20.0-3.fc20 tagged into tra | http://ur1.ca/ea995 | | 2013/07/04 | xhorak's firefox-21.0-4.fc19 untagged from f19 | http://ur1.ca/ea9a4 | | 2013/07/04 | xhorak's firefox-21.0-4.fc18 untagged from f18 | http://ur1.ca/ea9a1 | | 2013/07/03 | stransky's firefox-20.0-4.fc20 untagged from f | http://ur1.ca/ea9ac | | 2013/07/02 | pbrobinson's firefox-22.0-2.fc18 tagged into f | http://ur1.ca/ea9a1 | | 2013/07/02 | pbrobinson's firefox-22.0-2.fc18 completed | http://ur1.ca/enmvh | | 2013/07/02 | firefox-22.0-2.fc18 started building | http://ur1.ca/enmvh | +------------+------------------------------------------------+---------------------+
So the next time you're hacking on something and you say to yourself: "Wat wat wat. What just happened?" $ pkgwat history PKGNAME is another resource to draw on for clarity.
You can get the full help with $ pkgwat help history:
usage: pkgwat history [-h] [-f {csv,table}] [-c COLUMN] [--quote {all,minimal,none,nonnumeric}] [--rows-per-page ROWS_PER_PAGE] [--start-page PAGE] package Show the fedmsg history of a package. This command queries https://apps.fedoraproject.org/datagrepper/ positional arguments: package optional arguments: -h, --help show this help message and exit --rows-per-page ROWS_PER_PAGE --start-page PAGE output formatters: output formatter options -f {csv,table}, --format {csv,table} the output format, defaults to table -c COLUMN, --column COLUMN specify the column(s) to include, can be repeated CSV Formatter: --quote {all,minimal,none,nonnumeric} when to include quotes, defaults to nonnumeric
« Previous Page -- Next Page »