Re: [Cosign-discuss] cosign 3.2.0 does not build without patching on Apache 2.4.6, new release soon?
Let me clarify that I'm not saying CAS is deficient or that the extra stuff done by cosign is strictly necessary. I'm just saying why cosign does some of the things the way it does; there are, of course, other ways to do things. On 2015-02-07 11:35, Tom Boutell wrote: >> In addition to the cosign client web server verifying the certificate of >> the central weblogin server, the cosign client web server also presents >> a certificate of its own which the central weblogin server verifies. >> This way, the central weblogin server knows that it is in fact talking >> to a legitimate whitelisted client web server, which provides stronger >> assurance of the client webserver's identity than just IP and DNS >> information. This stronger assurance is good especially when proxying >> credentials such as Kerberos tickets from the central weblogin server to >> the client web servers. This is exactly the same as the assurance >> provided by HTTPS client certificates, if/when used. > OK, but the only way the client site can get the ticket in the first > place is via a redirect issued by the weblogin server, which won't > issue one to any other site. Yes, but how does the client site know that the ticket is legitimate? In the case of cosign service cookies, they are just random numbers. If a malicious party sends a request to the client web server with a fake cosign service cookie and somehow manages to intercept and reply to the validation request (such as man in the middle attack between the client web server and the central weblogin server) then they can say that the fake cosign service cookie is valid and get the client web server to give access to user data for arbitrary users. In the case of CAS, this attack is thwarted by verifying the CAS login server HTTPS certificate during the validation request; in the case of cosign, the attack is thwarted by verifying the central weblogin server back-channel certificate (which could be the same as the weblogin server HTTPS certificate, if you wanted) when the connection to the central weblogin server is established. >> This permits >> the cosign client web servers to maintain persistent connections to each >> of the central weblogin servers to avoid the overhead of frequent TLS >> session establishment. > OK, yes, I see there's a performance win there. The CAS callback > protocol might benefit from HTTP keep-alive in practice, but if logins > are spaced, say, 5 minutes apart, it probably won't. It's not just about logins: I don't know the details of CAS, but in addition to cosign checking the service cookie during when the user first accesses the client web server, the service cookie is checked with the central weblogin server for any future HTTPS request the user makes to the client web server, if the cookie has not been checked in the previous 60 seconds. These checks are how the client web server knows if the user has centrally logged out, among other things. It's also about load balancing and fault tolerance: a single client web server will attempt to keep persistent connections open to all central weblogin servers. The central weblogin servers make a "best effort" attempt to replicate all login session data between all of them, but in theory the central weblogin servers could become get out of sync with one another temporarily due to network failures / partitioning or other problems. When checking a cosign service cookie (either on first access or if 60 seconds have passed since a check caused by a previous access), the client web server will check with each of the central weblogin servers in turn until it finds one that can supply a definitive answer to the check. Since the connections to the central weblogin servers are persistent, these checks are very quick and efficient since TLS session establishment only needs to be attempted if a particular connection has failed AND if none of the other, still-open, connections returned a definitive answer. >> Cosign >> maintains its own list of trusted certificate authorities that is >> separate from the list of certificate authorities trusted by web >> browsers or web servers > Sure, but an attacker who could take advantage of this could also > impersonate both the weblogin site and the web client site, and their > browser would give them no indication that this was happening. Yep, but just because that's possible on the front end due to the broken nature of CA trusts for HTTPS certificates doesn't mean that having the option to configure things to prevent a CA-based attack on the back end is bad. I imagine you could achieve the same thing with CAS by configuring all of the non-user HTTPS traffic to go to a separate web virtual host on the CAS login server that used an in-house CA, required a valid HTTPS client certificate from the client web server signed by the same in-house CA for all requests, and had the client web servers only trust the in-house CA for t
Re: [Cosign-discuss] cosign 3.2.0 does not build without patching on Apache 2.4.6, new release soon?
Thanks for the thoughtful response. > The risk isn't with redirects, it's when the client web server contacts > the central weblogin server to verify the service cookie (ticket, in CAS > parlance, if I understand things correctly). CAS does this verification > via HTTPS, so that the client web server knows (by verifying the > certificate of the CAS login server when the HTTPS session is > established) that it is talking to a legitimate CAS login server rather > than to a man-in-the-middle or other imposter who might be lying about > the validity of the CAS ticket. The same is true with cosign: when a > client web server establishes a connection to a central weblogin server, > the connection is protected with TLS, and the client web server verifies > the certificate of the central weblogin server. Sure, so these are equal so far, although the one doesn't require a separate communication channel. > In addition to the cosign client web server verifying the certificate of > the central weblogin server, the cosign client web server also presents > a certificate of its own which the central weblogin server verifies. > This way, the central weblogin server knows that it is in fact talking > to a legitimate whitelisted client web server, which provides stronger > assurance of the client webserver's identity than just IP and DNS > information. This stronger assurance is good especially when proxying > credentials such as Kerberos tickets from the central weblogin server to > the client web servers. This is exactly the same as the assurance > provided by HTTPS client certificates, if/when used. OK, but the only way the client site can get the ticket in the first place is via a redirect issued by the weblogin server, which won't issue one to any other site. > Note that while CAS client website uses HTTPS to query the CAS login > server, cosign client web servers query the central weblogin servers > using a cosign-specific protocol sent over a TLS session. This permits > the cosign client web servers to maintain persistent connections to each > of the central weblogin servers to avoid the overhead of frequent TLS > session establishment. OK, yes, I see there's a performance win there. The CAS callback protocol might benefit from HTTP keep-alive in practice, but if logins are spaced, say, 5 minutes apart, it probably won't. > Cosign > maintains its own list of trusted certificate authorities that is > separate from the list of certificate authorities trusted by web > browsers or web servers -- if cosign's trusted CA list is set to be only > the in-house certificate authority, attackers who compromise commercial > certificate authorities ( > https://www.google.com/#q=certificate+authority+compromised ) will not > be able to issue certificates to subvert cosign back-channel > communications. (Note that the University of Michigan currently uses > its own in-house CA for its central weblogin servers' back-channel > certificate; client web server back-channel certificates can be either > from the same CA or from a list of 3-4 specific trusted commercial CAs). Sure, but an attacker who could take advantage of this could also impersonate both the weblogin site and the web client site, and their browser would give them no indication that this was happening. So they would be able to steal your users' credentials anyway, at least in the common "logging in with a username and password on the web login server" case. Again, thanks for responding so thoughtfully! -- THOMAS BOUTELL, DEV & OPS P'UNK AVENUE | (215) 755-1330 | punkave.com -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
Re: [Cosign-discuss] cosign 3.2.0 does not build without patching on Apache 2.4.6, new release soon?
On 2015-02-06 20:22, Tom Boutell wrote: > Since the login server never redirects with a ticket to any site but > one of its whitelisted client websites, and always with https, and the > client website always uses https to call back to the login server, I > don't see a risk of man-in-the-middle attack there so far. But I could > be missing something. The risk isn't with redirects, it's when the client web server contacts the central weblogin server to verify the service cookie (ticket, in CAS parlance, if I understand things correctly). CAS does this verification via HTTPS, so that the client web server knows (by verifying the certificate of the CAS login server when the HTTPS session is established) that it is talking to a legitimate CAS login server rather than to a man-in-the-middle or other imposter who might be lying about the validity of the CAS ticket. The same is true with cosign: when a client web server establishes a connection to a central weblogin server, the connection is protected with TLS, and the client web server verifies the certificate of the central weblogin server. In addition to the cosign client web server verifying the certificate of the central weblogin server, the cosign client web server also presents a certificate of its own which the central weblogin server verifies. This way, the central weblogin server knows that it is in fact talking to a legitimate whitelisted client web server, which provides stronger assurance of the client webserver's identity than just IP and DNS information. This stronger assurance is good especially when proxying credentials such as Kerberos tickets from the central weblogin server to the client web servers. This is exactly the same as the assurance provided by HTTPS client certificates, if/when used. Note that while CAS client website uses HTTPS to query the CAS login server, cosign client web servers query the central weblogin servers using a cosign-specific protocol sent over a TLS session. This permits the cosign client web servers to maintain persistent connections to each of the central weblogin servers to avoid the overhead of frequent TLS session establishment. Finally, while cosign is most frequently configured to use and trust the same certificates used by HTTPS, because cosign does not use HTTPS for its back-channel traffic, the option exists to use different certificates for the back-channel traffic than is used for web traffic. For example, cosign can use its own in-house certificate authority for either the central weblogin server back-channel certificates, for the cosign client web server back-channel certificates, or both. Cosign maintains its own list of trusted certificate authorities that is separate from the list of certificate authorities trusted by web browsers or web servers -- if cosign's trusted CA list is set to be only the in-house certificate authority, attackers who compromise commercial certificate authorities ( https://www.google.com/#q=certificate+authority+compromised ) will not be able to issue certificates to subvert cosign back-channel communications. (Note that the University of Michigan currently uses its own in-house CA for its central weblogin servers' back-channel certificate; client web server back-channel certificates can be either from the same CA or from a list of 3-4 specific trusted commercial CAs). -- Mark Montague m...@catseye.org -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
Re: [Cosign-discuss] cosign 3.2.0 does not build without patching on Apache 2.4.6, new release soon?
Interesting. In the CAS scheme, the login server redirects the browser back to the client website, with a unique ticket. The client website then calls back to the login server to verify the ticket is legitimate, and the login server responds with the username and other metadata. Since the login server never redirects with a ticket to any site but one of its whitelisted client websites, and always with https, and the client website always uses https to call back to the login server, I don't see a risk of man-in-the-middle attack there so far. But I could be missing something. On Fri, Feb 6, 2015 at 6:36 PM, Mark Montague wrote: > On 2015-02-06 17:11, Tom Boutell wrote: >> >> One of the key differences between Cosign and CAS seems to be the >> implementation of separate SSL certificates for Cosign's back-channel. >> I'm curious what the improvement in security is there. It could be >> left over from the era when the public sites might not be using https, >> or it could have a larger benefit that just isn't clear to me yet. > > > What Liam said: on virtually all of our web servers we use the same > certificate for connecting to the central weblogin servers that we use for > HTTPS. As for the improvement to security, the certificates are needed to > be sure that the client web server is talking to the real central weblogin > servers, that there is no man in the middle eavesdropping on or modifying > the traffic, and so that the central weblogin servers know that they are > talking to a legitimate client web server belonging to the institution > rather than random machines. > > -- > Mark Montague > m...@catseye.org > -- THOMAS BOUTELL, DEV & OPS P'UNK AVENUE | (215) 755-1330 | punkave.com -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
Re: [Cosign-discuss] cosign 3.2.0 does not build without patching on Apache 2.4.6, new release soon?
On 2015-02-06 17:11, Tom Boutell wrote: > One of the key differences between Cosign and CAS seems to be the > implementation of separate SSL certificates for Cosign's back-channel. > I'm curious what the improvement in security is there. It could be > left over from the era when the public sites might not be using https, > or it could have a larger benefit that just isn't clear to me yet. What Liam said: on virtually all of our web servers we use the same certificate for connecting to the central weblogin servers that we use for HTTPS. As for the improvement to security, the certificates are needed to be sure that the client web server is talking to the real central weblogin servers, that there is no man in the middle eavesdropping on or modifying the traffic, and so that the central weblogin servers know that they are talking to a legitimate client web server belonging to the institution rather than random machines. -- Mark Montague m...@catseye.org -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
Re: [Cosign-discuss] cosign 3.2.0 does not build without patching on Apache 2.4.6, new release soon?
While its a different configuration option from the vhost's SSL setting, they don't have to be separate certificates (as long as the cosign server recognizes the CA that signed the browser facing cert) Liam On Friday, February 6, 2015, Tom Boutell wrote: > Thanks for the pointers. It would be a lot more approachable to do new > implementations of cosign if there were a spec document like this one: > > > http://jasig.github.io/cas/development/protocol/CAS-Protocol-Specification.html > > One of the key differences between Cosign and CAS seems to be the > implementation of separate SSL certificates for Cosign's back-channel. > I'm curious what the improvement in security is there. It could be > left over from the era when the public sites might not be using https, > or it could have a larger benefit that just isn't clear to me yet. > > -- > > > THOMAS BOUTELL, DEV & OPS > P'UNK AVENUE | (215) 755-1330 | punkave.com > > > -- > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net/ > ___ > Cosign-discuss mailing list > Cosign-discuss@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/cosign-discuss > -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
Re: [Cosign-discuss] cosign 3.2.0 does not build without patching on Apache 2.4.6, new release soon?
Thanks for the pointers. It would be a lot more approachable to do new implementations of cosign if there were a spec document like this one: http://jasig.github.io/cas/development/protocol/CAS-Protocol-Specification.html One of the key differences between Cosign and CAS seems to be the implementation of separate SSL certificates for Cosign's back-channel. I'm curious what the improvement in security is there. It could be left over from the era when the public sites might not be using https, or it could have a larger benefit that just isn't clear to me yet. -- THOMAS BOUTELL, DEV & OPS P'UNK AVENUE | (215) 755-1330 | punkave.com -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
Re: [Cosign-discuss] cosign 3.2.0 does not build without patching on Apache 2.4.6, new release soon?
There is a lighttpd implementation, and a previous maintainer was working on an nginx implementation.. wonder if we could get that from him. Sounds like you're considering implementing it in node.js? Liam On Tue, Feb 3, 2015 at 9:50 AM, Tom Boutell wrote: > Thanks, that's a very helpful response. Also nice to know there's > active maintenance of Cosign itself happening at Penn, since that's > where we are called upon to use it. > > While I've got your attention, I'm curious whether there's a single > document anywhere that documents the protocol that the Apache cosign > module actually implements. Currently there is no implementation in > node.js, or for nginx, so we're stuck using Apache as a proxy for > cosign projects only. We've already written a node implementation of > CAS, and I'm curious whether the cosign protocol - or the part of it > that is really used and needed for hosting a site, not a trust source > - is similarly straightforward or has hidden cryptographic depths. (: > > On Tue, Feb 3, 2015 at 8:29 AM, Jorj Bauer wrote: > > Hi Tom, > > > > Yes, we're working on a new release. We have a few details in mid-stride > (shifting the repository main from SourceForge to github, moving the > website, changing release managers) and as soon as we've got those nailed > down, we should have a new release. It's been slow progress but we are > getting there. > > > > The repo that you found is valid, and when complete, will be the new > home of our source. Right now it's slightly out of sync with development > efforts as we're moving toward a more github-decentralized style. In > particular, see my repo, in which I'm teasing apart pieces of Penn > functionality to support Duo 2-factor logins, multi-threaded worker > support, and some other details: > > > > https://github.com/JorjBauer/cosign > > > > As we get close to a release candidate, you'll hear more. Right now > we're knee deep in alligators. > > > > -- Jorj > > > > > > On Feb 2, 2015, at 7:03 PM, Tom Boutell wrote: > > > >> I found it necessary to patch filters/apache2/mod_cosign.c and replace > >> all occurrences of remote_ip with client_ip. I was then able to build > >> successfully. > >> > >> I then went looking for a github repository and discovered it is > >> already fixed here: > >> > >> > https://github.com/cosignweblogin/cosign/blob/master/filters/apache2/mod_cosign.c > >> > >> But there are no links to that repo from weblogin.org. > >> > >> What's the status of the 3.2.1 release? Is there a roadmap? > >> > >> Thanks! > >> > >> -- > >> > >> > >> THOMAS BOUTELL, DEV & OPS > >> P'UNK AVENUE | (215) 755-1330 | punkave.com > >> > >> > -- > >> Dive into the World of Parallel Programming. The Go Parallel Website, > >> sponsored by Intel and developed in partnership with Slashdot Media, is > your > >> hub for all things parallel software development, from weekly thought > >> leadership blogs to news, videos, case studies, tutorials and more. > Take a > >> look and join the conversation now. http://goparallel.sourceforge.net/ > >> ___ > >> Cosign-discuss mailing list > >> Cosign-discuss@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/cosign-discuss > > > > > > -- > > > THOMAS BOUTELL, DEV & OPS > P'UNK AVENUE | (215) 755-1330 | punkave.com > > > -- > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net/ > ___ > Cosign-discuss mailing list > Cosign-discuss@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/cosign-discuss > -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
Re: [Cosign-discuss] cosign 3.2.0 does not build without patching on Apache 2.4.6, new release soon?
Take a look at this: http://weblogin.org/overview.shtml It includes both the HTTP redirect sequence & the back channel protocol. Missing are the STARTTLS bit, which are more or less obvious. :wes On 03 Feb 2015, at 09:50, Tom Boutell wrote: > While I've got your attention, I'm curious whether there's a single > document anywhere that documents the protocol that the Apache cosign > module actually implements. Currently there is no implementation in > node.js, or for nginx, so we're stuck using Apache as a proxy for > cosign projects only. We've already written a node implementation of > CAS, and I'm curious whether the cosign protocol - or the part of it > that is really used and needed for hosting a site, not a trust source > - is similarly straightforward or has hidden cryptographic depths. (: -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
Re: [Cosign-discuss] cosign 3.2.0 does not build without patching on Apache 2.4.6, new release soon?
Thanks, that's a very helpful response. Also nice to know there's active maintenance of Cosign itself happening at Penn, since that's where we are called upon to use it. While I've got your attention, I'm curious whether there's a single document anywhere that documents the protocol that the Apache cosign module actually implements. Currently there is no implementation in node.js, or for nginx, so we're stuck using Apache as a proxy for cosign projects only. We've already written a node implementation of CAS, and I'm curious whether the cosign protocol - or the part of it that is really used and needed for hosting a site, not a trust source - is similarly straightforward or has hidden cryptographic depths. (: On Tue, Feb 3, 2015 at 8:29 AM, Jorj Bauer wrote: > Hi Tom, > > Yes, we're working on a new release. We have a few details in mid-stride > (shifting the repository main from SourceForge to github, moving the website, > changing release managers) and as soon as we've got those nailed down, we > should have a new release. It's been slow progress but we are getting there. > > The repo that you found is valid, and when complete, will be the new home of > our source. Right now it's slightly out of sync with development efforts as > we're moving toward a more github-decentralized style. In particular, see my > repo, in which I'm teasing apart pieces of Penn functionality to support Duo > 2-factor logins, multi-threaded worker support, and some other details: > > https://github.com/JorjBauer/cosign > > As we get close to a release candidate, you'll hear more. Right now we're > knee deep in alligators. > > -- Jorj > > > On Feb 2, 2015, at 7:03 PM, Tom Boutell wrote: > >> I found it necessary to patch filters/apache2/mod_cosign.c and replace >> all occurrences of remote_ip with client_ip. I was then able to build >> successfully. >> >> I then went looking for a github repository and discovered it is >> already fixed here: >> >> https://github.com/cosignweblogin/cosign/blob/master/filters/apache2/mod_cosign.c >> >> But there are no links to that repo from weblogin.org. >> >> What's the status of the 3.2.1 release? Is there a roadmap? >> >> Thanks! >> >> -- >> >> >> THOMAS BOUTELL, DEV & OPS >> P'UNK AVENUE | (215) 755-1330 | punkave.com >> >> -- >> Dive into the World of Parallel Programming. The Go Parallel Website, >> sponsored by Intel and developed in partnership with Slashdot Media, is your >> hub for all things parallel software development, from weekly thought >> leadership blogs to news, videos, case studies, tutorials and more. Take a >> look and join the conversation now. http://goparallel.sourceforge.net/ >> ___ >> Cosign-discuss mailing list >> Cosign-discuss@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/cosign-discuss > -- THOMAS BOUTELL, DEV & OPS P'UNK AVENUE | (215) 755-1330 | punkave.com -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
Re: [Cosign-discuss] cosign 3.2.0 does not build without patching on Apache 2.4.6, new release soon?
Hi Tom, Yes, we're working on a new release. We have a few details in mid-stride (shifting the repository main from SourceForge to github, moving the website, changing release managers) and as soon as we've got those nailed down, we should have a new release. It's been slow progress but we are getting there. The repo that you found is valid, and when complete, will be the new home of our source. Right now it's slightly out of sync with development efforts as we're moving toward a more github-decentralized style. In particular, see my repo, in which I'm teasing apart pieces of Penn functionality to support Duo 2-factor logins, multi-threaded worker support, and some other details: https://github.com/JorjBauer/cosign As we get close to a release candidate, you'll hear more. Right now we're knee deep in alligators. -- Jorj On Feb 2, 2015, at 7:03 PM, Tom Boutell wrote: > I found it necessary to patch filters/apache2/mod_cosign.c and replace > all occurrences of remote_ip with client_ip. I was then able to build > successfully. > > I then went looking for a github repository and discovered it is > already fixed here: > > https://github.com/cosignweblogin/cosign/blob/master/filters/apache2/mod_cosign.c > > But there are no links to that repo from weblogin.org. > > What's the status of the 3.2.1 release? Is there a roadmap? > > Thanks! > > -- > > > THOMAS BOUTELL, DEV & OPS > P'UNK AVENUE | (215) 755-1330 | punkave.com > > -- > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net/ > ___ > Cosign-discuss mailing list > Cosign-discuss@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/cosign-discuss -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
[Cosign-discuss] cosign 3.2.0 does not build without patching on Apache 2.4.6, new release soon?
I found it necessary to patch filters/apache2/mod_cosign.c and replace all occurrences of remote_ip with client_ip. I was then able to build successfully. I then went looking for a github repository and discovered it is already fixed here: https://github.com/cosignweblogin/cosign/blob/master/filters/apache2/mod_cosign.c But there are no links to that repo from weblogin.org. What's the status of the 3.2.1 release? Is there a roadmap? Thanks! -- THOMAS BOUTELL, DEV & OPS P'UNK AVENUE | (215) 755-1330 | punkave.com -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
