[12:54:12 CDT(-0500)] <battags> hello CAS folks!
[12:54:22 CDT(-0500)] <serac> howdy
[12:54:49 CDT(-0500)] <battags> did you get hit with the 100 degree day yesterday?
[12:55:00 CDT(-0500)] <serac> It was hot as hell, but didn't go that high.
[12:55:10 CDT(-0500)] <serac> Was practically dripping humidity, tho, which is terrible.
[12:55:21 CDT(-0500)] <battags> they had half days for the schools
[12:55:25 CDT(-0500)] <serac> Whoa.
[12:55:27 CDT(-0500)] <battags> almost no humidity day
[12:55:32 CDT(-0500)] <battags> NJ kids are wimps though 
[12:55:38 CDT(-0500)] <battags> most schools have no AC either
[12:55:43 CDT(-0500)] <serac> Really?
[12:55:48 CDT(-0500)] <serac> It's not that far north.
[12:55:55 CDT(-0500)] <serac> That should breed them tough.
[12:56:55 CDT(-0500)] <battags> you would think
[12:57:01 CDT(-0500)] <serac> I've actually got something to talk about today.
[12:57:20 CDT(-0500)] <battags> I figured when you Imed me and Andrew emailed me
[12:57:35 CDT(-0500)] <serac> Been studying CAS4 (cas3/trunk just to be clear to others) lately and working on trying to identify some points to help simplify and clear up API.
[12:57:51 CDT(-0500)] <serac> But I've run into lots of things that I need to get clear on.
[12:58:03 CDT(-0500)] <serac> Let's just pick one today so I don't get overwhelmed.
[12:58:06 CDT(-0500)] <battags> ha
[12:58:07 CDT(-0500)] <battags> ok
[12:58:10 CDT(-0500)] <serac>
[12:58:13 CDT(-0500)] <battags> let's home I can remember
[12:58:27 CDT(-0500)] <serac> It's okay to study your notes
[12:58:32 CDT(-0500)] <apetro> hope springs eternal.
[12:58:53 CDT(-0500)] <serac> Let me take a sec to make sure I say this right.
[12:58:55 CDT(-0500)] <serac> ...
[12:59:10 CDT(-0500)] <serac> (studying code)
[13:01:28 CDT(-0500)] <serac> DefaultAuthenticationResponseImpl takes Set<Authentication>, each of which has a single principal.
[13:01:53 CDT(-0500)] <serac> I can imagine a need for multiple principals, but why this way?
[13:02:20 CDT(-0500)] <serac> I think of the authentication as a single event.
[13:02:23 CDT(-0500)] <serac> yes/no
[13:02:35 CDT(-0500)] <serac> Seems there should be only one that can have multiple principals.
[13:03:19 CDT(-0500)] <battags> the authentication respresents each credential attempt
[13:04:11 CDT(-0500)] <battags> though I thought we resolve to one principal anyway
[13:04:20 CDT(-0500)] <battags> each Authentication should map directly to a passed in credential
[13:04:23 CDT(-0500)] <serac> I see some code to do that.
[13:04:41 CDT(-0500)] <battags> I can't vouch that the code to resolve works
[13:04:45 CDT(-0500)] <battags> but in theory it should do that
[13:04:49 CDT(-0500)] <serac> Sure, but it's there iirc.
[13:04:59 CDT(-0500)] <serac> I understand the model now.
[13:05:01 CDT(-0500)] <battags> and we then attach a single principal to the Session
[13:05:27 CDT(-0500)] <serac> What's the value of carrying around multiple Authentications?
[13:05:54 CDT(-0500)] <serac> They're attached persistently to the Session unless I'm missing something.
[13:05:59 CDT(-0500)] <battags> yes
[13:06:09 CDT(-0500)] <battags> we keep them for the multi-factor use case
[13:06:12 CDT(-0500)] <battags> later in life
[13:06:38 CDT(-0500)] <battags> i.e. you need to authenticate if you don't have an RSA token authentication
[13:06:49 CDT(-0500)] <serac> I'd argue the principal should serve that purpose.
[13:06:50 CDT(-0500)] <battags> or maybe you should re-authenticate if you have an RSA token
[13:07:10 CDT(-0500)] <battags> so you want a principal with multiple authentication methods attached to it?
[13:07:12 CDT(-0500)] <serac> Tag each principal with the authentication source.
[13:07:29 CDT(-0500)] <battags> but then you can have a principal with different names
[13:07:32 CDT(-0500)] <serac> Then each authentication carries multiple authenticated princpals.
[13:07:35 CDT(-0500)] <serac> I know that's an issue.
[13:07:43 CDT(-0500)] <serac> But it's one I expect to happen in practice.
[13:07:56 CDT(-0500)] <battags> there was a discussion on this at some point
[13:08:06 CDT(-0500)] <battags> it might have been on a Yale MFA call
[13:08:12 CDT(-0500)] <serac> We have discussed it.
[13:08:26 CDT(-0500)] <battags> where we decided that the simplification should be at the principal level
[13:08:33 CDT(-0500)] <battags> i.e. if you already have a TGT
[13:08:50 CDT(-0500)] <battags> and you come in with a different principal something happens
[13:08:53 CDT(-0500)] <battags> either an error or the invalidation of the previous TGT
[13:10:07 CDT(-0500)] <apetro> indeed. A single principal can be authenticated in multiple ways with different metadata on those authentications, but a single SSO session can accomodate only one authenticated principal at a time.
[13:10:50 CDT(-0500)] <serac> Not saying otherwise.
[13:11:13 CDT(-0500)] <serac> We could still handle this with multiple principals on the Auth and resolve to a single on the Session.
[13:11:43 CDT(-0500)] <serac> I'm not trying to push this design, tho, really.
[13:12:49 CDT(-0500)] <serac> What I observed is that there's data bound to the Authentication that will be needlessly repeated for multiple credentials.
[13:12:59 CDT(-0500)] <serac> e.g. Date, LongTerm, possible AuthMethod
[13:13:12 CDT(-0500)] <serac> Maybe some of the metadata.
[13:13:23 CDT(-0500)] <battags> well meta data is for that authentication object
[13:13:29 CDT(-0500)] <battags> I could see long term being moved off
[13:13:34 CDT(-0500)] <battags> its really a notion of the session
[13:13:44 CDT(-0500)] <battags> date is for each authentication
[13:14:01 CDT(-0500)] <serac> Yeah, but they'll vary by ms in most cases and might as well be same.
[13:14:13 CDT(-0500)] <battags> until MFA really takes off
[13:15:12 CDT(-0500)] <serac> Ok, move LongTerm off and I'm good. I think you justified that design nicely.
[13:16:23 CDT(-0500)] <battags> are we relying on the chat log as notes?
[13:16:56 CDT(-0500)] <battags> or do we want to open tickets for these?
[13:16:59 CDT(-0500)] <serac> Yeah, no sense writing down what LogBot is doing automagically.
[13:17:04 CDT(-0500)] <battags> not sure why I'm on a JIRA kick ha
[13:17:46 CDT(-0500)] <serac> I think I'd like to distill these design recommendations into a single set.
[13:18:40 CDT(-0500)] <serac> I think we've got time for another.
[13:18:46 CDT(-0500)] <serac> (and energy)
[13:19:47 CDT(-0500)] <battags> that one was pretty painless
[13:19:48 CDT(-0500)] <battags> :-p
[13:20:01 CDT(-0500)] <serac> Sessions are self-referential like TGT is currently.
[13:21:12 CDT(-0500)] <serac> I think the "can't renew topmost TGT" problem is one issue that's come up with that design.
[13:21:27 CDT(-0500)] <serac> This is in the context of proxy tickets.
[13:21:46 CDT(-0500)] <serac> I see there are getRootX() methods that may help alleviate that issue.
[13:21:52 CDT(-0500)] <serac> Why not just keep it flat, though?
[13:21:57 CDT(-0500)] <serac> One session per user.
[13:27:02 CDT(-0500)] <apetro> how strongly do you mean "per user"?
[13:27:09 CDT(-0500)] <apetro> as in, per principal?
[13:27:22 CDT(-0500)] <battags> we typically consider the prox-ier a user
[13:27:31 CDT(-0500)] <serac> had a feeling
[13:27:42 CDT(-0500)] <apetro> proxy-ers are Principals, are they not?
[13:27:50 CDT(-0500)] <battags> yes
[13:27:53 CDT(-0500)] <serac> Currently they are.
[13:27:58 CDT(-0500)] <apetro> so do we mean one Session per Principal?
[13:28:11 CDT(-0500)] <serac> I'm thinking strictly data structures here.
[13:28:12 CDT(-0500)] <apetro> or do we mean "Don't deliberately open two TGTs at once 
"
[13:28:22 CDT(-0500)] <serac> Session either has children or not.
[13:28:28 CDT(-0500)] <apetro> right
[13:28:30 CDT(-0500)] <serac> Thinking about JPA, it's bad.
[13:28:47 CDT(-0500)] <serac> And I'm thinking a lot about JPA since there's a lot of room for improvement from 3.4.
[13:28:59 CDT(-0500)] <apetro> heh. Nicely played, sir.
[13:29:19 CDT(-0500)] <serac> I'm wondering if we could model it more simply.
[13:29:21 CDT(-0500)] <battags> there's a lot of changes to the JPA support
[13:29:22 CDT(-0500)] <serac> Just wondering.
[13:29:24 CDT(-0500)] <apetro> so the children of Sessions we're talking about here are Sessions for proxying Principals aka Services, right?
[13:29:24 CDT(-0500)] <battags> in 4
[13:29:29 CDT(-0500)] <battags> yes
[13:29:38 CDT(-0500)] <battags> just like the normal TGT/PGT heirarchy
[13:29:45 CDT(-0500)] <apetro> yup
[13:29:55 CDT(-0500)] <apetro> those are convenient relationships to model hierarchically
[13:30:13 CDT(-0500)] <apetro> since killing a Session anywhere in that tree should kill all its children
[13:31:08 CDT(-0500)] <apetro> there's a loosely related side thought to have here about ability to issue multiple Session cookies to a single Browser, and the answer to that should be No, that you can only have zero or one Sessions per Browser at a time.
[13:31:49 CDT(-0500)] <apetro> (and since Session has exactly one Principal, that gets the desired One Principal at a Time effect on browsers)
[13:31:49 CDT(-0500)] <serac> Here's the core question:
[13:31:57 CDT(-0500)] <serac> Are these chains or trees?
[13:32:09 CDT(-0500)] <serac> They're modeled like trees, but we colloquially call them chains.
[13:32:28 CDT(-0500)] <apetro> a chain is a view on a tree
[13:32:33 CDT(-0500)] <apetro> they're trees
[13:32:35 CDT(-0500)] <serac> pfft
[13:32:41 CDT(-0500)] <apetro> but from the perspective of any leaf, it's a chain
[13:32:55 CDT(-0500)] <battags> ha
[13:33:00 CDT(-0500)] <apetro> it's like this.
[13:33:39 CDT(-0500)] <serac> I get the abstraction.
[13:33:43 CDT(-0500)] <apetro> Andrew logs in to Timesheet via CAS. Then he logs into uPortal. uPortal proxies out to seven different fascinating services. Then Andrew logs into SharePoint. After much struggling and pain, SharePoint proxies out to five more backing services.
[13:34:30 CDT(-0500)] <apetro> Then Andrew logs out of uPortal and (perhaps through a mechanism as yet undeveloped, but which ought to exist), uPortal, being Prudent, kills its Session
[13:34:32 CDT(-0500)] <battags> I think the current abstraction works for the most part except for influencing your parent
[13:34:45 CDT(-0500)] <serac> So each of the 7 uPortal services has created a Session?
[13:34:46 CDT(-0500)] <battags> i.e. stuff happens downstream but not upstream
[13:34:56 CDT(-0500)] <serac> That is an issue at present, yes.
[13:34:58 CDT(-0500)] <apetro> Maybe
[13:34:58 CDT(-0500)] <battags> only uPortal should have a session
[13:35:06 CDT(-0500)] <apetro> those downstream services had the opportunity to create sessions
[13:35:15 CDT(-0500)] <apetro> if they wanted to then proxy to something else
[13:35:29 CDT(-0500)] <battags> anything that requests a PGT in the old world would have a session in the new world
[13:35:30 CDT(-0500)] <apetro> in the abstract, anyway, there's a case for zapping part of the tree but not the whole tree.
[13:35:53 CDT(-0500)] <serac> So each proxied service that wants to proxy claims uPortal as parent, so it's one:many.
[13:36:06 CDT(-0500)] <apetro> Right. So I'd need another paragraph or so to include the portlet that talks to a servlet that proxy-cas-authenticates to an IMAP server and serves as an IMAP-to-XML-gateway.
[13:36:19 CDT(-0500)] <apetro> Parents can have multiple children, yes.
[13:36:29 CDT(-0500)] <serac> My lack of real-world experience with proxies is hurting me for this discussion.
[13:36:32 CDT(-0500)] <apetro> a given Session can have zero to many children.
[13:36:46 CDT(-0500)] <apetro> well, it's a fair criticism that in the real world, presently, mostly this isn't real
[13:36:54 CDT(-0500)] <apetro> it's not actually true that uPortal can kill its PGT, I don't think
[13:36:59 CDT(-0500)] <apetro> but it probably should be able to.
[13:37:14 CDT(-0500)] <apetro> and certainly it is presently true that uPortal's PGT can expire
[13:37:29 CDT(-0500)] <apetro> and can expire differentially from other PGTs stemming from the root TGT
[13:38:27 CDT(-0500)] <serac> We need to be able to solve the practical problem of expiration when you've got these proxy trees. (Let's start calling them that.)
[13:38:52 CDT(-0500)] <serac> I'm convinced we have to model them this way.
[13:39:04 CDT(-0500)] <apetro> that's fine. They're proxy trees from the server's perpective, which is certainly the annoyance that CAS needs to persist
[13:39:23 CDT(-0500)] <apetro> they're chains from the relying party perspective, in that it's none of the relying party's business what the rest of the tree looks like.
[13:39:31 CDT(-0500)] <battags> so the simplest solution is that all interaction with a child is funneled through its parent and then a parent would know its been used
[13:39:42 CDT(-0500)] <battags> the alternative is for the child to notify the parent
[13:40:01 CDT(-0500)] <apetro> hmmm, clarify "know"
[13:40:08 CDT(-0500)] <apetro> as in the backing web applications involved get notified?
[13:40:15 CDT(-0500)] <apetro> or as in the Java objects server-side get tickled?
[13:40:22 CDT(-0500)] <battags> the tickled scenario
[13:40:23 CDT(-0500)] <battags> lol
[13:40:25 CDT(-0500)] <serac> I read it the latter way.
[13:40:31 CDT(-0500)] <serac> I wonder if we'll regret that.
[13:40:33 CDT(-0500)] <apetro> k
[13:40:41 CDT(-0500)] <battags> its better than Andrew's usual turtle example
[13:40:43 CDT(-0500)] <apetro> eh
[13:41:03 CDT(-0500)] <serac> We may not want that coupling in some cases.
[13:41:07 CDT(-0500)] <apetro> invent Web Services for a Relying Party to query CAS for metadata about its outstanding Session, and it can check up on these things
[13:41:13 CDT(-0500)] <apetro> ala actual NAU solution, btw
[13:41:31 CDT(-0500)] <serac> That's interesting.
[13:41:40 CDT(-0500)] <apetro> so, maybe we need to back up to goals
[13:41:42 CDT(-0500)] <serac> I think we're still at the server side, tho.
[13:41:44 CDT(-0500)] <apetro> just slightly, a bit
[13:42:02 CDT(-0500)] <apetro> since an algorithm whereby a Session can be extended Forever has some downsides.
[13:42:04 CDT(-0500)] <serac> How do we handle expiration policy at the server. Just that one case, for proxy trees.
[13:42:18 CDT(-0500)] <serac> That's just it – it can't at present be extended.
[13:42:25 CDT(-0500)] <apetro> well
[13:42:38 CDT(-0500)] <serac> The "root" TGT isn't touched when PTs are issued down the chain.
[13:42:44 CDT(-0500)] <apetro> what's the current situation? A soft timeout, and a hard timeout, with the soft timeout being snooze-barred by use, up to the hard limit of the hard timeout?
[13:42:54 CDT(-0500)] <serac> So the expiration policy kills the whole thing prematurely.
[13:43:14 CDT(-0500)] <apetro> hmm
[13:43:40 CDT(-0500)] <apetro> this explains NAU customization to walk the tree tickling tickets when PTs are exercised downstream in the tree
[13:43:44 CDT(-0500)] <serac> The most flexible solution is to try to give ExpirationPolicy more data to make a decision.
[13:44:01 CDT(-0500)] <apetro> and give relying parties a way to actively kill their sessions, yes
[13:44:19 CDT(-0500)] <apetro> longer clock time timeouts are a little more acceptable when the service / user can actively kill them
[13:44:24 CDT(-0500)] <serac> I think that's a nice control handle, provided it's secured properly.
[13:44:31 CDT(-0500)] <apetro> right
[13:44:45 CDT(-0500)] <apetro> ok
[13:45:00 CDT(-0500)] <apetro> flexible ExpirationPolicy APIs are great
[13:45:14 CDT(-0500)] <apetro> to sanity check, tho, what data do we envision would be relevant input?
[13:45:29 CDT(-0500)] <apetro> timestamps of downstream ticket issuance/use (leaves of the tree)?
[13:45:59 CDT(-0500)] <apetro> I suppose Authentication metadata
[13:46:09 CDT(-0500)] <apetro> I'm uncomfortable with longTerm ness being a boolean
[13:46:19 CDT(-0500)] <serac> Safest thing would be to give it a Session object and then it could, e.g. walk the tree or not.
[13:46:28 CDT(-0500)] <apetro> it's kind of more a nuance of expiration policy in sober consideration of metadata like how authenticated, user preference, etc.
[13:46:40 CDT(-0500)] <apetro> indeed
[13:46:59 CDT(-0500)] <apetro> I agree that the API should get to look at the whole Session
[13:47:06 CDT(-0500)] <serac> There's a downside tho.
[13:47:23 CDT(-0500)] <apetro> still, trying to think through what it's going to do to sanity check whether that's likely to be sufficient and clean
[13:47:25 CDT(-0500)] <serac> One thing we're trying to support is DELETE FROM Session WHERE IS_EXPIRED=true.
[13:47:27 CDT(-0500)] <serac> Or similar.
[13:47:46 CDT(-0500)] <serac> We can't do that now, and the more complex an interface ExpirationPolicy takes, the harder it will be to do.
[13:48:11 CDT(-0500)] <apetro> background thread that iterates over Sessions, applies ExpirationPolicy, and can zap whatever fails the test?
[13:48:31 CDT(-0500)] <apetro> I mean, the issue being solved here is cleanup, right, so persisted Sessions don't expand to inifinity?
[13:48:36 CDT(-0500)] <battags> the CAS4 session storage supports two APIs
[13:49:06 CDT(-0500)] <battags> the "quick" one if you use a relatively easy expiration policy that you can recreate as a query
[13:49:08 CDT(-0500)] <serac> Problem with iteration is the use of JPA means buffering them all in memory – ugh.
[13:49:19 CDT(-0500)] <battags> and the annoying one that loads tickets (though it loads a batch at a time)
[13:49:24 CDT(-0500)] <battags> tickets = sessions
[13:49:33 CDT(-0500)] <apetro> right
[13:49:41 CDT(-0500)] <apetro> it's not a matter of buffering them all in memory all at once
[13:49:53 CDT(-0500)] <serac> That's a big practical matter.
[13:50:25 CDT(-0500)] <battags> its why CAS 4 supports both models
[13:50:27 CDT(-0500)] <apetro> eh. Gotta be able to rehydrate these things on demand in response to attempts to use the Sessions anyway
[13:50:40 CDT(-0500)] <battags> and forces batching if you want to actually check the expiration policy
[13:50:52 CDT(-0500)] <serac> I don't see that API, Scott.
[13:50:57 CDT(-0500)] <serac> Got a src ref?
[13:51:17 CDT(-0500)] <serac> I'm looking at Session and don't see it.
[13:51:28 CDT(-0500)] <battags> give me one sec
[13:51:29 CDT(-0500)] <apetro> ( wgthom , what's happening, anything interesting to report/query/input whilst we're here?)
[13:51:33 CDT(-0500)] <serac> SessionStorage, excuse me.
[13:51:56 CDT(-0500)] <apetro> ( EricDalquist , what's happening, anything interesting to report/query/input whilst we're here?)
[13:52:18 CDT(-0500)] <EricDalquist> huh?
[13:52:18 CDT(-0500)] <apetro> ( smaresca , what's happening, anything interesting to report/query/input whilst we're here?)
[13:52:47 CDT(-0500)] <battags> https://source.jasig.org/cas3/trunk/cas-server-sessionstorage-jpa/src/main/java/org/jasig/cas/server/session/SimpleCleanupJpaSessionStorageImpl.java
[13:52:48 CDT(-0500)] <apetro> just poking people lurking in chat room to see if any issues needing discussed during this time window when serac , battags , and I are synchronously here.)
[13:52:50 CDT(-0500)] <battags> is the query based one
[13:53:04 CDT(-0500)] <battags> https://source.jasig.org/cas3/trunk/cas-server-sessionstorage-jpa/src/main/java/org/jasig/cas/server/session/ExpirationBasedCleanupJpaSessionStorageImpl.java
[13:53:05 CDT(-0500)] <EricDalquist> oh ok ... I'm going back to lurking then
[13:53:09 CDT(-0500)] <battags> in theory supports batching
[13:53:17 CDT(-0500)] <serac> Got it, tx.
[13:53:23 CDT(-0500)] <battags> the unit tests pass but I didn't try with like 9000 tickets in the test
[13:53:56 CDT(-0500)] <apetro> a unit test does not a load test make.
[13:54:20 CDT(-0500)] <serac> Looks nice, Scott.
[13:54:32 CDT(-0500)] <serac> Nice call on batching.
[13:54:44 CDT(-0500)] <serac> That should address 90% of the complaints.
[13:56:27 CDT(-0500)] <apetro> as we run out of time in our designated hour: CAS 3.4.8 release?
[13:56:56 CDT(-0500)] <battags> do you mean 3.4.9?
[13:56:59 CDT(-0500)] <serac> I'm happy to do it, but I need a task list.
[13:57:17 CDT(-0500)] <serac> We never completed the 3.4.8 release, insofar as communication/announcements.
[13:57:18 CDT(-0500)] <apetro> I don't think I mean 3.4.9, no
[13:57:19 CDT(-0500)] <battags> so 3.4.8 was released just not announced
[13:57:27 CDT(-0500)] <battags> 3.4.9 needs to go out soon
[13:57:37 CDT(-0500)] <apetro> if a CAS release falls into a directory, and no one is told, does it make a sound?
[13:57:44 CDT(-0500)] <serac> haha
[13:57:50 CDT(-0500)] <apetro> http://www.jasig.org/cas links 3.4.7 as the latest release
[13:58:00 CDT(-0500)] <battags> yes because that was part of the announcement process :-p
[13:58:22 CDT(-0500)] <battags> but seriously if we're going to do 3.4.9 soon should be just prioritize that
[13:58:25 CDT(-0500)] <battags> ?
[13:58:29 CDT(-0500)] <battags> I have a few things I'm going to commit on Sunday
[13:58:34 CDT(-0500)] <serac> I was kind of thinking the same thing.
[13:58:44 CDT(-0500)] <battags> let me also grab the list of things to do I put in the wiki
[13:58:50 CDT(-0500)] <battags> I also want to fix the session time out
[13:58:54 CDT(-0500)] <battags> for the login flow
[13:58:56 CDT(-0500)] <serac> Can you share the link?
[13:58:57 CDT(-0500)] <battags> not sure how that stopped working
[13:59:02 CDT(-0500)] <battags> yeah I'm going to grab it now
[13:59:03 CDT(-0500)] <apetro> I don't think cleanup on 3.4.8 has to be a huge mountain rather than a molehill, but it needs to have some elevation to it.
[13:59:26 CDT(-0500)] <apetro> like, at this point the release can have the flavor of "3.4.8 exists but you shouldn't use it and instead should use 3.4.9"
[13:59:44 CDT(-0500)] <serac> That sounds like a good compromise.
[14:00:00 CDT(-0500)] <apetro> but some amount of these steps really do need done
[14:00:01 CDT(-0500)] <serac> You expect a release this weekend, Scott?
[14:00:13 CDT(-0500)] <apetro> this page, for instance: http://www.jasig.org/cas/download it's gotta list the release, and link to a page that says something intelligent about it.
[14:00:28 CDT(-0500)] <battags> I expect to finish my work on the weekend
[14:00:45 CDT(-0500)] <battags> I expect we should formalize the "vote" for release
[14:00:46 CDT(-0500)] <serac> I can fill those out if you hold my hand on getting into the CMS.
[14:00:52 CDT(-0500)] <battags> https://wiki.jasig.org/display/CAS/Release+Process
[14:01:06 CDT(-0500)] <apetro> serac , you'd emailed me about that
[14:01:06 CDT(-0500)] <battags> it is missing the generation of the SHA and MD5 values for the zip /tar files
[14:01:10 CDT(-0500)] <apetro> want to work through CMS access now?
[14:01:23 CDT(-0500)] <battags> and it has some notes from me on improvements to the process
[14:01:29 CDT(-0500)] <battags> though not all my suggestions for improvements
[14:01:47 CDT(-0500)] <apetro> might be difficult to capture all the suggestions for improvements
[14:01:48 CDT(-0500)] <battags> and there is stuff we need to define (i.e. the criteria for release)
[14:02:01 CDT(-0500)] <battags> well I'm pragmatic
[14:02:10 CDT(-0500)] <battags> I could sit around improving things all day
[14:02:11 CDT(-0500)] <battags> but then we'd never release
[14:02:21 CDT(-0500)] <serac> hashes of the downloads is another important step
[14:02:26 CDT(-0500)] <battags> I prefer iterative improvement
[14:02:31 CDT(-0500)] <apetro> agile, even
[14:02:35 CDT(-0500)] <battags> let's be clear its hashes of the zip / tar downloads
[14:02:41 CDT(-0500)] <battags> we generate the maven ones already
[14:02:48 CDT(-0500)] <serac> Whatever assembly generates, yes.
[14:02:51 CDT(-0500)] <battags> i wish we had a breakdown of who uses what method
[14:03:00 CDT(-0500)] <battags> there is a way to get download stats for Maven I believe
[14:03:13 CDT(-0500)] <apetro> eh
[14:03:18 CDT(-0500)] <apetro> this falls under trappings of projectness
[14:03:39 CDT(-0500)] <serac> We should discuss release voting at next casst mtg.
[14:03:43 CDT(-0500)] <apetro> people expect binary downloads, and hashes, even if most people don't actually validate the hashes
[14:04:01 CDT(-0500)] <apetro> (be honest: when's the last time you validated a Tomcat download's hash code?)
[14:04:04 CDT(-0500)] <serac> For security-related software, it's standard practice.
[14:04:15 CDT(-0500)] <serac> I verify the PGP sigs every time. Am I a dork?
[14:04:17 CDT(-0500)] <apetro> indeed. We have to do it because verone does it.
[14:04:25 CDT(-0500)] <battags> i actually wish something did it automatically
[14:04:31 CDT(-0500)] <apetro> no, you're just a better man than I, serac.
[14:04:44 CDT(-0500)] <battags> so we had 726 downloads of the webapp last month
[14:04:49 CDT(-0500)] <battags> 2K downloads of the client
[14:04:51 CDT(-0500)] <battags> from Maven
[14:05:09 CDT(-0500)] <serac> Do we have stats on the dist bundles?
[14:05:13 CDT(-0500)] <battags> april had 1024
[14:05:20 CDT(-0500)] <battags> you mean the assembly?
[14:05:30 CDT(-0500)] <apetro> hmm. That sounds low. Though I suppose there's aggressive downstream caching at work.
[14:05:35 CDT(-0500)] <serac> Yeah, stuff on jasig.org/cas/downloads/
[14:05:41 CDT(-0500)] <battags> we'd probably have to parse the apache log files
[14:05:45 CDT(-0500)] <serac> ugh
General
Content
Integrations