CAC enabled git

[caneridge]

Has anyone made any progress setting up CAC enabled git? 

I read this topic "Subversion, Redmine, CAC, and Self-Signed" which was related to this subject but it appears to have not been posted to in a while. 

Brian

[David Dyess]

I haven't, but I too would like to know if anyone has had any success with it.

David

--
You received this message because you are subscribed to the "Military Open Source Software" Google Group.
To post to this group, send email to mil...@googlegroups.com
To unsubscribe from this group, send email to mil-oss+u...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mil-oss?hl=en
 
www.mil-oss.org

[Josh Doe]

On Mon, May 21, 2012 at 11:21 PM, caneridge <cane...@gmail.com> wrote:
> Has anyone made any progress setting up CAC enabled git?

Not that I know of, but I'm certainly interested in seeing progress on
this. I've been lazy and haven't put our stuff up on
Software.Forge.mil yet because everything I have is in git and I don't
want to be bothered to downgrade to SVN.
-Josh

[David Dyess]

Haha, same here!

[Congdon, Benjamin E CIV DISA CTO]

While I'm not allowed to mess with our touch git with a 100ft. pole (per Agency policy :( ), I hear the common consensus is to use Apache httpd to front git. You can then set up Apache to do all the pki authentication work. I don't know how to get that working with the git client though, maybe the apache method only give you repo viewing through https? Or maybe the git client works fine that way?

On a side note, git is in the roadmap for software.forge.mil, or that is what the git forge.mil change request tracker comments say.

-ben

-----Original Message-----
From: mil...@googlegroups.com [mailto:mil...@googlegroups.com] On Behalf Of David Dyess
Sent: Tuesday, May 22, 2012 6:47 AM
To: mil...@googlegroups.com
Subject: Re: [mil-oss] CAC enabled git

Haha, same here!


On Tue, May 22, 2012 at 5:07 AM, Josh Doe <jo...@joshdoe.com> wrote:


On Mon, May 21, 2012 at 11:21 PM, caneridge <cane...@gmail.com> wrote:
> Has anyone made any progress setting up CAC enabled git?


Not that I know of, but I'm certainly interested in seeing progress on
this. I've been lazy and haven't put our stuff up on
Software.Forge.mil yet because everything I have is in git and I don't
want to be bothered to downgrade to SVN.
-Josh


--
You received this message because you are subscribed to the "Military Open Source Software" Google Group.
To post to this group, send email to mil...@googlegroups.com

To unsubscribe from this group, send email to mil-oss+u...@googlegroups.com <mailto:mil-oss%2Bunsu...@googlegroups.com>

[Jennings, Jared L CTR USAF AFMC 46 SK/CCI]

I looked at it once, a few years ago. As far as I figured out, you can
only read a repository using http[s] with git, not send changes into it;
so CAC support via HTTPS (while it could be easy to implement) is only
half of what you need. You'd probably get farther by enabling SSH with a
CAC than by enabling HTTPS with a CAC.

> -----Original Message-----
> From: mil...@googlegroups.com [mailto:mil...@googlegroups.com] On
> Behalf Of David Dyess
> Sent: Tuesday, May 22, 2012 4:20 AM
> To: mil...@googlegroups.com
> Subject: Re: [mil-oss] CAC enabled git
>

> I haven't, but I too would like to know if anyone has had any success
> with it.
>
> David
>
>
> On Mon, May 21, 2012 at 10:21 PM, caneridge <cane...@gmail.com>
> wrote:
>
>
> Has anyone made any progress setting up CAC enabled git?
>
> I read this topic "Subversion, Redmine, CAC, and Self-Signed"
> which was related to this subject but it appears to have not been
> posted to in a while.
>
> Brian
>
>
> --
> You received this message because you are subscribed to the
> "Military Open Source Software" Google Group.
> To post to this group, send email to mil...@googlegroups.com
> To unsubscribe from this group, send email to mil-

> oss+uns...@googlegroups.com <mailto:mil-
> oss%2Bunsu...@googlegroups.com>

> For more options, visit this group at
> http://groups.google.com/group/mil-oss?hl=en
>
> www.mil-oss.org
>
>
>

> --
> You received this message because you are subscribed to the "Military
> Open Source Software" Google Group.
> To post to this group, send email to mil...@googlegroups.com
> To unsubscribe from this group, send email to mil-

> oss+uns...@googlegroups.com

[caneridge]

Can we send you a 101ft pole? What are the key reasons pushing back to not use git?

On Tuesday, May 22, 2012 6:15:00 AM UTC-7, Congdon, Benjamin E CIV DISA CTO wrote:

While I'm not allowed to mess with our touch git with a 100ft. pole (per Agency policy :( ), I hear the common consensus is to use Apache httpd to front git.  You can then set up Apache to do all the pki authentication work.  I don't know how to get that working with the git client though, maybe the apache method only give you repo viewing through https?  Or maybe the git client works fine that way?

On a side note, git is in the roadmap for software.forge.mil, or that is what the git forge.mil change request tracker comments say.

-ben


-----Original Message-----
From: mil...@googlegroups.com [mailto:mil-oss@googlegroups.com] On Behalf Of David Dyess
Sent: Tuesday, May 22, 2012 6:47 AM
To: mil...@googlegroups.com
Subject: Re: [mil-oss] CAC enabled git

Haha, same here!

On Tue, May 22, 2012 at 5:07 AM, Josh Doe <j> wrote:

        On Mon, May 21, 2012 at 11:21 PM, caneridge <> wrote:
        > Has anyone made any progress setting up CAC enabled git?
        
        
        Not that I know of, but I'm certainly interested in seeing progress on
        this. I've been lazy and haven't put our stuff up on
        Software.Forge.mil yet because everything I have is in git and I don't
        want to be bothered to downgrade to SVN.
        -Josh
        

        --
        You received this message because you are subscribed to the "Military Open Source Software"  Google Group.
        To post to this group, send email to mil...@googlegroups.com

        To unsubscribe from this group, send email to mil-oss+unsubscribe@googlegroups.com <mailto:mil-oss%2Bunsubscribe@googlegroups.com>

        For more options, visit this group at http://groups.google.com/group/mil-oss?hl=en
        
        www.mil-oss.org
        


--
You received this message because you are subscribed to the "Military Open Source Software" Google Group.
To post to this group, send email to mil...@googlegroups.com

To unsubscribe from this group, send email to mil-oss+unsubscribe@googlegroups.com

[caneridge]

All

I've started a topic on forge.mil here:

Subject: CAC enabled git

https://software.forge.mil/sf/discussion/do/listPosts/projects.community_cac/discussion.general_discussion.topc7004 

Please chime in to the post. Maybe a discussion on forge.mil will help things along.

Brian

[Gunnar Hellekson]

Will someone take responsibility to report back any substantive progress on forge.mil, as few on this list have access to it?

g

> --
> You received this message because you are subscribed to the "Military Open Source Software" Google Group.
> To post to this group, send email to mil...@googlegroups.com

> To unsubscribe from this group, send email to mil-oss+u...@googlegroups.com

[Brian Jones]

I'll cross post.

[caneridge]

From forge.mil:

Brian,

 	I've never looked at CAC enabling Git (since I don't use it).  I 
have submitted patches for Fossil to support S/MIME signed commits in 
addition to GPG signed commits.

I assume you are wanting something similar ?

I believe Git has the same support for GPG signed commits, so the changes 
would be generally the same:
 	1. Verify signatures on manifests (done by an external program in Fossil)
 	2. Strip signatures on manifests ( http://www.rkeene.org/viewer/tmp/fossil-6ca400a315-add-smime-support-1rsk.diff.htm 
)
 	3. Add signatures to manifests (done by an external program in Fossil)

The verification is trivially done with OpenSSL since the certificate 
authorities are usually not accessed via PKCS#11.

The addition of the signatures can also be done with OpenSSL using the 
PKCS#11 engine from the OpenSC project, or it's fairly simple to write 
your own code to talk to the PKCS#11 provider and ask it to perform the 
cryptographic operation and have OpenSSL SMIME it.

Thanks,
 	Roy Keene

On Tue, 22 May 2012, Brian Jones wrote:

> Has anyone pursued setting up CAC enabled git (PKCS#11)? We are working towards using git on our highly distributed 
unclass project for the Navy for government side source hosting. It would really help if there was support from the 
forge.mil community on setting up CAC enabled git.
>
> My assumption from what I've learned so far is that git over CAC enabled SSH would be the way to go although I am not 
a CAC or a SSH expert.
>
> Brian
> _______________________________________________
>
> General Discussion
> https://software.forge.mil/sf/go/post13837

[caneridge]

From forge.mil:

Roy,

Right. To provide some context, we are looking at a government hosted git repository that users need a CAC card (and 
possibly login credentials) to clone and some kind of assurance of who committed to clones as changes propagate back to 
the government repositories. Clones live on the contractor side and can be re-cloned to setup change flow through two or
 more git repositories.

We need the mechanism you describe for the contractor side commits.

Brian

[Wheeler, David A]

The good news is that git version 1.7.9 (released January 2012) has support for signed tags, which improves support for checking that committers are who they say they are.  If CAC support is to be added, I’d like to see those integrated (which SHOULD be easy, though those are famous last words).

 

More info available about git signed tags are at:

http://git-blame.blogspot.com/2012/01/git-179.html

https://lwn.net/Articles/473220/

http://git-blame.blogspot.com/2012/01/using-signed-tag-in-pull-requests.html

http://git-blame.blogspot.com/2011/08/how-to-inject-malicious-commit-to-git.html

https://plus.google.com/102150693225130002912/posts/jXEoT2Acrvm

http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/RelNotes/1.7.9.txt;h=95320aad5dd2414efeacbc088b34e45c4ac51bbf;hb=828ea97de486c1693d6e4f2c7347acb50235a85d

 

In particular, “the resulting merge commit records the content of the signed tag, so that other people can verify that the branch merged by the integrator was signed by the contributor, without fetching the signed tag used to validate the pull request separately and keeping it in the refs namespace.”

 

--- David A. Wheeler

--

[Howard Cohen]

I will. I work for Forge.Mil.

Howie Cohen

[caneridge]

From forge.mil:

Re: CAC enabled git 

CAC-Enabled SSH should get you what you need right? It doesn't sound like CAC-Enabling Git specifically is necessary, 
unless you want developers to sign every commit to their local git repository with their CAC (A little hard to enforce I
 would think, but I don't know much about that).

Rather I would say you want developers to access the git remote "origin" over ssh using the RSA keypair on the CAC for 
authentication.  If this is what you want to do, then I cam currently working on a soultion which does exactly that.

OpenSSH (I've said this before) supports PKCS11 out of the box, read the ssh-add man page and look for the -s option.  
You can use your CAC to authenticate you to an SSH server provided that you have installed the public portion of the CAC
 RSA keypair on the server in your authorized_keys file.  (This is all Linux, I hope that I can accoplish the same thing
 on Windows with PuttySC)

The problem in this space is there is no way to ensure that
1. Everyones authorized_keys file only contains public keys from CAC cards.
2. None of the certificates from which those public keys came have been revoked.

I am in the final stages of enabling my openssh server to overcome both of these problems, ensuring that users are 
connecting via SSH with their CAC and their certificate is not revoked.  It may be applicable to what you want to do, 
but you'll need access to an OCSP server to use my solution, and I'm probably going to have to check with my 
organization before I release anything to anyone.

Also, for anyone reading this, if there is already a known solution to what I am talking about, I would be very 
interested in knowing it.

-Andrew

[Gunnar Hellekson]

Thanks, Howard!

g

[caneridge]

From forge.mil:

Re: CAC enabled git 

Andrew,

 	I solved that problem a few years ago.  I wrote a patch against 
the client SSH Agent to support forwarding the user's certificate through 
the SSH Agent and also to support raw hashing.

This enabled me to write a PKCS#11 provider that talked to the local SSH 
agent socket, which talked to the SSH agent on the workstation attached to 
the smartcard which talked the PKCS#11 provider that talks PC/SC to the 
reader and passes APDUs to the card.

The end result is that my CAC is available on machines I login to.  I use 
this with pam_pkcs11 for PAM on remote hosts (to things like "sudo") but I 
haven't verified that it works for authentication natively during SSH. 
I'm sure with a bit of work that could be accomplished.

Note that the only thing I have modified here is the client's SSH agent. 
At one point I was going to port these changes to PuTTy's SSH agent but 
I've never been inclined to do so.

Thanks,
 	Roy Keene

[Wheeler, David A]

> CAC-Enabled SSH should get you what you need right? It doesn't sound like CAC-Enabling Git specifically is necessary,  unless you want developers to sign every commit to their local git repository with their CAC (A little hard to enforce I  would think, but I don't know much about that).

 

Actually, I *would* like to see something *like* this.  There’s an intermediate: tagging a particular version, and signing *that* version with a CAC.  Git now supports signed tags, so that they are stored in the repository & can be verified by third parties later.  It’s be nice to be *able* to sign every git commit too, actually; it’s not that hard.  But I think signing tags is the better way.

 

--- David A. Wheeler

 

 

 

 

From: mil...@googlegroups.com [mailto:mil...@googlegroups.com] On Behalf Of caneridge
Sent: Tuesday, May 22, 2012 4:56 PM
To: mil...@googlegroups.com
Subject: Re: [mil-oss] Re: CAC enabled git

 

From forge.mil:

 

Re: CAC enabled git 

Rather I would say you want developers to access the git remote "origin" over ssh using the RSA keypair on the CAC for 

authentication.  If this is what you want to do, then I cam currently working on a soultion which does exactly that.

OpenSSH (I've said this before) supports PKCS11 out of the box, read the ssh-add man page and look for the -s option.  

You can use your CAC to authenticate you to an SSH server provided that you have installed the public portion of the CAC

 RSA keypair on the server in your authorized_keys file.  (This is all Linux, I hope that I can accoplish the same thing

 on Windows with PuttySC)

The problem in this space is there is no way to ensure that

1. Everyones authorized_keys file only contains public keys from CAC cards.

2. None of the certificates from which those public keys came have been revoked.

I am in the final stages of enabling my openssh server to overcome both of these problems, ensuring that users are 

connecting via SSH with their CAC and their certificate is not revoked.  It may be applicable to what you want to do, 

but you'll need access to an OCSP server to use my solution, and I'm probably going to have to check with my 

organization before I release anything to anyone.

Also, for anyone reading this, if there is already a known solution to what I am talking about, I would be very 

interested in knowing it.

-Andrew

--

[Congdon, Benjamin E CIV DISA CTO]

Git is not approved by our CIO for use on the network we currently have access to and use every day for administrative tasks. Git is also considered a development tool which are all flat out verboten on that network per policy. We would only be able to use git on a commercial internet circuit where we would develop applications, however that request did not make the GIG waiver process. Our group is desperately seeking a network with an internet/NIPR gateway to do development on but we have not found one yet that our CIO would allow us to use (even DREN). The issue is not necessarily git it is any compiler; gcc, JDK, etc... These are not allowed on these networks. While you may not need a compiler for git... what is the use if I can't develop anything to put in git. I might be able to use it for revision control of documents/binary/text/whatever but we have SharePoint for that (sorry) :) We ARE allowed to "develop" on a standalone, isolated machine, but that is unusable as a development environment.


-ben

-----Original Message-----
From: mil...@googlegroups.com [mailto:mil...@googlegroups.com] On Behalf Of caneridge

Sent: Tuesday, May 22, 2012 12:29 PM
To: mil...@googlegroups.com
Subject: Re: [mil-oss] CAC enabled git

Can we send you a 101ft pole? What are the key reasons pushing back to not use git?

On Tuesday, May 22, 2012 6:15:00 AM UTC-7, Congdon, Benjamin E CIV DISA CTO wrote:

While I'm not allowed to mess with our touch git with a 100ft. pole (per Agency policy :( ), I hear the common consensus is to use Apache httpd to front git. You can then set up Apache to do all the pki authentication work. I don't know how to get that working with the git client though, maybe the apache method only give you repo viewing through https? Or maybe the git client works fine that way?

On a side note, git is in the roadmap for software.forge.mil, or that is what the git forge.mil change request tracker comments say.

-ben


-----Original Message-----
From: mil...@googlegroups.com [mailto:mil...@googlegroups.com <mailto:mil...@googlegroups.com> ] On Behalf Of David Dyess
Sent: Tuesday, May 22, 2012 6:47 AM
To: mil...@googlegroups.com
Subject: Re: [mil-oss] CAC enabled git

Haha, same here!

On Tue, May 22, 2012 at 5:07 AM, Josh Doe <j <mailto:jo...@joshdoe.com> > wrote:


On Mon, May 21, 2012 at 11:21 PM, caneridge <> wrote:
> Has anyone made any progress setting up CAC enabled git?


Not that I know of, but I'm certainly interested in seeing progress on
this. I've been lazy and haven't put our stuff up on
Software.Forge.mil yet because everything I have is in git and I don't
want to be bothered to downgrade to SVN.
-Josh


--
You received this message because you are subscribed to the "Military Open Source Software" Google Group.
To post to this group, send email to mil...@googlegroups.com

To unsubscribe from this group, send email to mil-oss+u...@googlegroups.com <mailto:mil-oss%2Bunsu...@googlegroups.com> <mailto:mil-oss%2Bunsu...@googlegroups.com <mailto:mil-oss%252Buns...@googlegroups.com> >
For more options, visit this group at http://groups.google.com/group/mil-oss?hl=en <http://groups.google.com/group/mil-oss?hl=en>

www.mil-oss.org



--
You received this message because you are subscribed to the "Military Open Source Software" Google Group.
To post to this group, send email to mil...@googlegroups.com

To unsubscribe from this group, send email to mil-oss+u...@googlegroups.com <mailto:mil-oss%2Bunsu...@googlegroups.com>
For more options, visit this group at http://groups.google.com/group/mil-oss?hl=en <http://groups.google.com/group/mil-oss?hl=en>

www.mil-oss.org



--
You received this message because you are subscribed to the "Military Open Source Software" Google Group.
To post to this group, send email to mil...@googlegroups.com

To unsubscribe from this group, send email to mil-oss+u...@googlegroups.com

[Wheeler, David A]

In my mind, what's clearly needed is a simple way to buy a service that is an network-accessible development environment. Send somebody $500, and within 1 day you get a network-accessible virtual machine with RHEL or Windows and a passel of development tools (gcc/Java/whatever, git/subversion/whatever, vi/emacs/Eclipse, etc.) so that you can do software development (with maybe $100/year maintenance fees). Perhaps DISA's "Server Hosting and Virtualization" could be used to do this, but I don't think it's designed to do that at all. My fee numbers aren't real; my point is that if the prices are too high, people won't use them (we *have* to have realistic cost figures!).

Just having a forge with CM (subversion/git) + bugtracker (bugzilla), like forge.mil, doesn't help if you can't download the code somewhere, change it, test it, and then post/submit it back. In many places in the commercial world this is a non-event, you just install the software, but that's a big complication in many places in the DoD.

--- David A. Wheeler

[Kit Plummer]

Yup.  That's a good start.  I think what's more important is the endpoint for the developed goods.  Imagine an "approved" Heroku/CloudFoundry/OpenShift PAAS environment where adjudicated apps/services could go to.  If you have that, then the dev environment problem gets really easy.

[ben congdon]

That is exactly what we're working for right now and we have high-level support for it finally.  While it is not a 100% solution it is a good start. We're hoping DISA's RACE can change a couple configuration settings (and maybe the price) and then we'd be up and running in a development environment.  Currently RACE is more in tune to be a a test/integration/pre-prod environment of pre-developed code.

The goal is to also be able to develop on DREN or some other DoD development network that has a gateway to the Internet using a real machine at my desk, but that seems to be further down the road (read: impossible).

-ben

To unsubscribe from this group, send email to mil-oss+unsubscribe@googlegroups.com <mailto:mil-oss%2Bunsubscribe@googlegroups.com> <mailto:mil-oss%2Bunsubscribe@googlegroups.com <mailto:mil-oss%252Bunsubscribe...@googlegroups.com> >

For more options, visit this group at http://groups.google.com/group/mil-oss?hl=en <http://groups.google.com/group/mil-oss?hl=en>

www.mil-oss.org

--

You received this message because you are subscribed to the "Military Open Source Software" Google Group.

To post to this group, send email to mil...@googlegroups.com

To unsubscribe from this group, send email to mil-oss+unsubscribe@googlegroups.com <mailto:mil-oss%2Bunsubscribe@googlegroups.com>

For more options, visit this group at http://groups.google.com/group/mil-oss?hl=en <http://groups.google.com/group/mil-oss?hl=en>

www.mil-oss.org

--

You received this message because you are subscribed to the "Military Open Source Software" Google Group.

To post to this group, send email to mil...@googlegroups.com

To unsubscribe from this group, send email to mil-oss+unsubscribe@googlegroups.com

For more options, visit this group at http://groups.google.com/group/mil-oss?hl=en

www.mil-oss.org

--

You received this message because you are subscribed to the "Military Open Source Software" Google Group.

To post to this group, send email to mil...@googlegroups.com

To unsubscribe from this group, send email to mil-oss+unsubscribe@googlegroups.com

To unsubscribe from this group, send email to mil-oss+unsubscribe@googlegroups.com <mailto:mil-oss%2Bunsubscribe@googlegroups.com> <mailto:mil-oss%2Bunsubscribe@googlegroups.com <mailto:mil-oss%252Bunsubscribe...@googlegroups.com> >

For more options, visit this group at http://groups.google.com/group/mil-oss?hl=en <http://groups.google.com/group/mil-oss?hl=en>

www.mil-oss.org

--

You received this message because you are subscribed to the "Military Open Source Software" Google Group.

To post to this group, send email to mil...@googlegroups.com

To unsubscribe from this group, send email to mil-oss+unsubscribe@googlegroups.com <mailto:mil-oss%2Bunsubscribe@googlegroups.com>

For more options, visit this group at http://groups.google.com/group/mil-oss?hl=en <http://groups.google.com/group/mil-oss?hl=en>

www.mil-oss.org

--

You received this message because you are subscribed to the "Military Open Source Software" Google Group.

To post to this group, send email to mil...@googlegroups.com

To unsubscribe from this group, send email to mil-oss+unsubscribe@googlegroups.com

For more options, visit this group at http://groups.google.com/group/mil-oss?hl=en

www.mil-oss.org

--

You received this message because you are subscribed to the "Military Open Source Software" Google Group.

To post to this group, send email to mil...@googlegroups.com

To unsubscribe from this group, send email to mil-oss+unsubscribe@googlegroups.com

[Richard Bullington-McGuire]

It may not be good enough because it relies on the raw RSA keys on the token, not the certificate. Therefore you can't check the certificate for revocation, or have multiple certificates map into the same security principal on the back end.

To work like Subversion works, the client must support mutual SSL authentication. I'm the guy who baked support for CAC and SVN and a host of other SSL goodness into forge.mil in the first place, although I haven't worked on the project since Aug 2009.

--

Richard Bullington-McGuire

+1 571 236 0938

--

[Chuck Atkins]

You dont have to use git via ssh.  I've been using git with 2 way ssl via https for some time now using client side certs.  It's just as easy to set up (the client anyways) as svn.  Given that, it may already be feasible to use pkcs11 instead of a pem cert and key.  I believe git gets its https support from the underlying libcurl.  So if youre using curl-openssl then you configure the git client one way, if using curl-nss then you configure another way. Either way, you can already use 2 way ssl with client certs, just not sure how to point it to a cac for this since i use an ECA cert.

[Richard Bullington-McGuire]

The trick here is getting the git client to talk to the smart card to do SSL client certificate integration. I have looked at this multiple times over the past couple years. You typically need to modify the bottom half of the crypto stack so that it will negotiate using hardware tokens. This means enabling the openSSL or GNUtls options that will talk to the crypto card, and making sure that the higher level libraries (such as libcurl or APR) invoke the right functions at the right times. Remember that the application security STIG mandates mutually authenticated SSL.

--

Richard Bullington-McGuire  +1 571 236 0938

Sent from my iPad

[Richard Bullington-McGuire]

You are dead on here. The trick is pulling this off.

--

Richard Bullington-McGuire  +1 571 236 0938

Sent from my iPad

[Tim Meehle]

Anyone have any experience in meeting the security requirements of AR25-2 using PHP? My firm has a classic ASP App that needs updating. I'm leaning towards PHP but there are concerns from army. Any thoughts, advice, suggestion, links are greatly appreciated.

Thanks
Tim

Sent from my iPhone

[brlcad]

Ummm, isn't Content Online Resource Enterprise (CORE) built on PHP??  CORE runs www.army.mil and AKO, not to mention the use of Mediawiki and a bunch of other PHP-based web fronts elsewhere (at least on research portal).

Couldn't quickly find anything authoritative on the CORE website directly, but this news link seems to concur:

 

http://ohmygov.com/blogs/general_news/archive/2010/01/25/my-army-mil-sharing-the-army-story-in-a-digital-media-age.aspx

Maybe you're talking with someone entirely non-techincal, otherwise spitting out AR25-2 sounds like completely ignorant FUD.

Cheers!

Sean

On May 23, 2012, at 08:34 AM, Tim Meehle <t...@meehle.com> wrote:

Anyone have any experience in meeting the security requirements of AR25-2 using PHP? My firm has a classic ASP App that needs updating. I'm leaning towards PHP but there are concerns from army. Any thoughts, advice, suggestion, links are greatly appreciated.

Thanks
Tim

Sent from my iPhone

On May 22, 2012, at 5:33 PM, "Wheeler, David A" <dwhe...@ida.org> wrote:

> In my mind, what's clearly needed is a simple way to buy a service that is an network-accessible development environment. Send somebody $500, and within 1 day you get a network-accessible virtual machine with RHEL or Windows and a passel of development tools (gcc/Java/whatever, git/subversion/whatever, vi/emacs/Eclipse, etc.) so that you can do software development (with maybe $100/year maintenance fees). Perhaps DISA's "Server Hosting and Virtualization" could be used to do this, but I don't think it's designed to do that at all. My fee numbers aren't real; my point is that if the prices are too high, people won't use them (we *have* to have realistic cost figures!).
>
> Just having a forge with CM (subversion/git) + bugtracker (bugzilla), like forge.mil, doesn't help if you can't download the code somewhere, change it, test it, and then post/submit it back. In many places in the commercial world this is a non-event, you just install the software, but that's a big complication in many places in the DoD.
>
> --- David A. Wheeler
>
>
> -----Original Message-----
> From: mil...@googlegroups.com [mailto:mil...@googlegroups.com] On Behalf Of Congdon, Benjamin E CIV DISA CTO
> Sent: Tuesday, May 22, 2012 5:16 PM
> To: mil...@googlegroups.com
> Subject: RE: [mil-oss] CAC enabled git
>
> Git is not approved by our CIO for use on the network we currently have access to and use every day for administrative tasks. Git is also considered a development tool which are all flat out verboten on that network per policy. We would only be able to use git on a commercial internet circuit where we would develop applications, however that request did not make the GIG waiver process. Our group is desperately seeking a network with an internet/NIPR gateway to do development on but we have not found one yet that our CIO would allow us to use (even DREN). The issue is not necessarily git it is any compiler; gcc, JDK, etc... These are not allowed on these networks. While you may not need a compiler for git... what is the use if I can't develop anything to put in git. I might be able to use it for revision control of documents/binary/text/whatever but we have SharePoint for that (sorry) :) We ARE allowed to "develop" on a standalone, isolated machine, but that is unusable as a development environment
>
>
>

> -ben
>
>
> -----Original Message-----
> From: mil...@googlegroups.com [mailto:mil-oss@googlegroupscom] On Behalf Of caneridge
> Sent: Tuesday, May 22, 2012 12:29 PM
> To: mil...@googlegroups.com
> Subject: Re: [mil-oss] CAC enabled git
>
> Can we send you a 101ft pole? What are the key reasons pushing back to not use git?
>
> On Tuesday, May 22, 2012 6:15:00 AM UTC-7, Congdon, Benjamin E CIV DISA CTO wrote:
>
> While I'm not allowed to mess with our touch git with a 100ft. pole (per Agency policy :( ), I hear the common consensus is to use Apache httpd to front git. You can then set up Apache to do all the pki authentication work. I don't know how to get that working with the git client though, maybe the apache method only give you repo viewing through https? Or maybe the git client works fine that way?
>
> On a side note, git is in the roadmap for software.forge.mil, or that is what the git forge.mil change request tracker comments say.
>
> -ben
>
>
> -----Original Message-----
> From: mil...@googlegroups.com [mailto:mil...@googlegroups.com <mailto:mil...@googlegroups.com> ] On Behalf Of David Dyess
> Sent: Tuesday, May 22, 2012 6:47 AM
> To: mil...@googlegroups.com
> Subject: Re: [mil-oss] CAC enabled git
>
> Haha, same here!
>
>
> On Tue, May 22, 2012 at 5:07 AM, Josh Doe <j <mailto:jo...@joshdoe.com> > wrote:
>
>
> On Mon, May 21, 2012 at 11:21 PM, caneridge <> wrote:
>> Has anyone made any progress setting up CAC enabled git?
>
>
> Not that I know of, but I'm certainly interested in seeing progress on

> this I've been lazy and haven't put our stuff up on

> Software.Forge.mil yet because everything I have is in git and I don't
> want to be bothered to downgrade to SVN.
> -Josh
>
>
> --
> You received this message because you are subscribed to the "Military Open Source Software" Google Group.
> To post to this group, send email to mil...@googlegroups.com
> To unsubscribe from this group, send email to mil-oss+u...@googlegroups.com <mailto:mil-oss%2Bunsu...@googlegroups.com> <mailto:mil-oss%2Bunsu...@googlegroups.com <mailto:mil-oss%252Buns...@googlegroups.com> >
> For more options, visit this group at http://groups.google.com/group/mil-oss?hl=en <http://groups.google.com/group/mil-oss?hl=en>
>
> www.mil-oss.org
>
>
>
> --
> You received this message because you are subscribed to the "Military Open Source Software" Google Group.
> To post to this group, send email to mil...@googlegroups.com
> To unsubscribe from this group, send email to mil-oss+u...@googlegroups.com <mailto:mil-oss%2Bunsu...@googlegroups.com>
> For more options, visit this group at http://groups.google.com/group/mil-oss?hl=en <http://groups.google.com/group/mil-oss?hl=en>
>
> www.mil-oss.org
>
>
>
> --
> You received this message because you are subscribed to the "Military Open Source Software" Google Group.
> To post to this group, send email to mil...@googlegroups.com
> To unsubscribe from this group, send email to mil-oss+u...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/mil-oss?hl=en
>

> wwwmil-oss.org

[Jennings, Jared L CTR USAF AFMC 46 SK/CCI]

> You dont have to use git via ssh. I've been using git with 2 way ssl
> via https for some time now using client side certs.

What?! I must have been under a rock somewhere.

> I believe git
> gets its https support from the underlying libcurl.

I made darcs fetch using a CAC once, by using libcurl-nss. I had to add
a couple of parameters to the libcurl calls in darcs, but it was all
boilerplate. After adding the CoolKey PKCS11 module to the NSS database
directory, I was able to fetch. But darcs couldn't push over https at
the time, so the experiment ended there.

So if you can both pull and push using git over https, and git uses
libcurl to do so, this route seems like it would be super easy. It
wouldn't necessarily make it easier to sign things in the repo, like
commits or tags, though.

[Kyle Harrigan]

Read-only has not been true since smart http was implemented.

See http://git-scm.com/2010/03/04/smart-http.html.

I think the main issue right now is that GIT uses curl for https and
curl does not support smartcards that I am aware of.

GIT works happily with CACs over SSH as mentioned later in the
thread. You can even handily put a reference the PKCS11Provider dll/
so in the .ssh/config file which makes it super handy. It also works
with SSH agent for caching credentials, although maybe that seems like
not such a good idea.

But since most organizations have issue opening port 22 https is still
the holy grail.

curl supports some kind of --engine argument which can theoretically
use a pkcs11 engine though google has not lead me to the answer yet.
This seemed like the right direction:

http://comments.gmane.org/gmane.comp.web.curl.general/11028


On May 22, 10:44 am, "Jennings, Jared L CTR USAF AFMC 46 SK/CCI"

<jared.jennings....@eglin.af.mil> wrote:
> I looked at it once, a few years ago. As far as I figured out, you can
> only read a repository using http[s] with git, not send changes into it;
> so CAC support via HTTPS (while it could be easy to implement) is only
> half of what you need. You'd probably get farther by enabling SSH with a
> CAC than by enabling HTTPS with a CAC.
>
>
>
>
>
>
>
> > -----Original Message-----
> > From: mil...@googlegroups.com [mailto:mil...@googlegroups.com] On
> > Behalf Of David Dyess
> > Sent: Tuesday, May 22, 2012 4:20 AM
> > To: mil...@googlegroups.com
> > Subject: Re: [mil-oss] CAC enabled git
>
> > I haven't, but I too would like to know if anyone has had any success
> > with it.
>
> > David
>

> > On Mon, May 21, 2012 at 10:21 PM, caneridge <caneri...@gmail.com>

[Kyle Harrigan]

Yeah that isn't practical for CAC cause you can't get the private key
off the CAC card (for good reason I might add... ;->)

You are right about CURL. I think the key is to get the curl --engine
call working by going to a pkcs11 library.

On May 22, 11:19 pm, Chuck Atkins <chuck.atk...@kitware.com> wrote:
> You dont have to use git via ssh.  I've been using git with 2 way ssl via
> https for some time now using client side certs.  It's just as easy to set
> up (the client anyways) as svn.  Given that, it may already be feasible to
> use pkcs11 instead of a pem cert and key.  I believe git gets its https
> support from the underlying libcurl.  So if youre using curl-openssl then
> you configure the git client one way, if using curl-nss then you configure
> another way. Either way, you can already use 2 way ssl with client certs,
> just not sure how to point it to a cac for this since i use an ECA cert.
> On May 22, 2012 8:04 PM, "Richard Bullington-McGuire" <
>
>
>
>
>
>
>
> richard.bullington.mcgu...@gmail.com> wrote:
> > It may not be good enough because it relies on the raw RSA keys on the
> > token, not the certificate. Therefore you can't check the certificate for
> > revocation, or have multiple certificates map into the same security
> > principal on the back end.
>
> > To work like Subversion works, the client must support mutual SSL
> > authentication. I'm the guy who baked support for CAC and SVN and a host of
> > other SSL goodness into forge.mil in the first place, although I haven't
> > worked on the project since Aug 2009.
>
> > --
> > Richard Bullington-McGuire
> > +1 571 236 0938
>

> > On May 22, 2012, at 4:59 PM, caneridge <caneri...@gmail.com> wrote:
>
> > *From forge.mil:*
>
> >>  *
> > *
> > Re: CAC enabled git <https://software.forge.mil/sf/discussion/do/listPosts/projects.commun...>

[Jennings, Jared L CTR USAF AFMC 46 SK/CCI]

> Read-only has not been true since smart http was implemented.
> See http://git-scm.com/2010/03/04/smart-http.html.

That's excellent.

> I think the main issue right now is that GIT uses curl for https and
> curl does not support smartcards that I am aware of.

No, but it does! All you have to do is build a curl that links against
NSS instead of OpenSSL. NSS supports PKCS#11 and has for a long time,
without any of this bolt-on engine stuff that OpenSSL makes you go
through. (I never could get OpenSSL to work with a CAC.) To switch
crypto libraries there is an argument you pass to libcurl's ./configure
script.

[Robot]

As an alternative to the native git program, I was able to get jgit to work with a CAC by getting Java to work with a CAC. There are actual two different ways to get Java to work with a CAC on Windows. One is to use the MSCAPI as the key/trust store provider and another is to add PKCS#11 support to Java.

This blog post (sorry requires CAC to access) details (with some source) how I "injected" CAC support into any Java program:

https://www.moesol.com/roller/rhastings/entry/inject_a_cac_identity_chooser

This wiki post details how to integrate the above with jgit:

https://cmsource.sd.spawar.navy.mil/confluence/display/c2rpc/CAC+authentication

Jerry Quassar was able to take what I did and bend it to use PKCS#11 so that it would work on Linux (that is the beauty of having the source!):

https://cmsource.sd.spawar.navy.mil/confluence/display/RITE/Using+git+with+CAC

Recently, I got MSCAPI to work with egit as well, so I can fetch and push inside of Eclipse now. However, I tried to use this technique with maven and I had to force it to use the default Java SSL handling to get it to work. So far, the subversion support in Eclipse does not work this way.

[Matthew]

Nice work.Unfortunately the project I was on, that this would have rocked on, I am no longer on as of last week. Humor me, anyone need an IA guy or Systems Engineer? btw I have a script to setup SVN and cac use. Same script also sets up firefox so you can check your email, within seconds of running it. Its Linux based though.

--

--
You received this message because you are subscribed to the "Military Open Source Software" Google Group.
To post to this group, send email to mil...@googlegroups.com
To unsubscribe from this group, send email to mil-oss+u...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mil-oss?hl=en
 
www.mil-oss.org
 

---
You received this message because you are subscribed to the Google Groups "Military Open Source Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mil-oss+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
SimonTek
912-398-6704

[Brett Stahlman]

I got it working under Cygwin. The process was very tedious and error-prone, so I encapsulated it in the following Bash script, maintained in Github:

 CAC-Enabled Git Setup

Note that the script is intended to work on either Linux or Windows (Cygwin)...

Brett S.

[Wheeler, David A]

> I got it working under Cygwin. The process was very tedious and error-prone, so I encapsulated it in the following Bash script, maintained in Github:

 

 CAC-Enabled Git Setup

 

That is very awesome!

 

This sort of capability should be enable-able by some run-time option using the native/standard builds.  What would it take to get there?

 

--- David A. Wheeler

 

[Brett Stahlman]

Thanks. Although there's a good bit of setup involved, only the curl and git sources require patching. The patches applied by the script are slightly modified versions of the ones developed by Jerry Quassar, referenced in the following post:

https://groups.google.com/d/msg/mil-oss/cROdK-Tq5sw/7xwTCRPuutAJ

In a nutshell, the capabilities added by the patches are as follows:

• Curl
• Enable dynamic loading of the PKCS#11 engine
• Permit user to define the path to a custom openssl configuration file with an environment variable (not critical, as you can simply add the PKCS#11 engine config to the default /usr/ssl/openssl.conf)
• Git
• Add support for several SSL-related options that are needed to configure the curl lib to use PKCS#11
• Permit user to disable the Tk-based "askpass" dialog, in favor of a tty prompt for passwords, pins, etc... (Now that Tk requires X, the default behavior can result in annoying errors for Cygwin users with no X server.)

It seems to me that at least some of these features could be generally useful. I see no reason why the functionality shouldn't be added to the respective projects...

Sincerely,

Brett S.

--- David A. Wheeler

 

[Wheeler, David A]

> Permit user to disable the Tk-based "askpass" dialog, in favor of a tty prompt for passwords, pins, etc... (Now that Tk requires X, the default behavior can result in annoying errors for Cygwin users with no X server.)

What’s wrong with the environment variable GIT_ASKPASS, which git already supports?

--- David A. Wheeler

[Matthew]

I have a copy og github enterprise,  i should test it on that.

Matthew M. Conley
912-398-6704

--

--
You received this message because you are subscribed to the "Military Open Source Software" Google Group.
To post to this group, send email to mil...@googlegroups.com
To unsubscribe from this group, send email to mil-oss+u...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mil-oss?hl=en
 
www.mil-oss.org

---
You received this message because you are subscribed to the Google Groups "Military Open Source Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mil-oss+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Brett Stahlman]

You're right. You can achieve the same thing with GIT_ASKPASS, simply by doing...

export GIT_ASKPASS=

I believe I tried this before adding the inhibit mechanism, but my global ~/.gitconfig was setting askpass to the Tk dialog for my Windows Git installation, and I wanted a way to say, "Just use the git_terminal_prompt no matter what sort of askpass programs are configured in the various configs". Still, as it turns out, I could have achieved the same thing by explicitly unsetting GIT_ASKPASS, so I'll probably remove that portion of the patch...

Thanks,

Brett S.

[Brett Stahlman]

On Wednesday, March 11, 2015 at 3:41:44 PM UTC-5, SimonTek wrote:

I have a copy og github enterprise,  i should test it on that.

Would be glad to hear how it went if you do...

Thanks,

Brett S.

[Jamie Jones]

Matthew, how did this end up working out?  Did you make any progress on CAC integration?

[Matthew]

To which, github enterprise? The enterprise version is fairly straight forward, I would have to hunt down my how-to I created.

SimonTek
912-398-6704

[Jamie Jones]

Enterprise, absolutely.  i was reading through old list archives that were talking about having to recompile openssl to make local git work, etc, so i'm assuming your work has super-ceded and improved on all of that.

I'd love whatever you have.

[Brett Stahlman]

Jamie,
The recompiles are still necessary; the purpose of the script is to automate the whole process...
Thanks, Brett S.

You received this message because you are subscribed to a topic in the Google Groups "Military Open Source Software" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mil-oss/cROdK-Tq5sw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mil-oss+u...@googlegroups.com.

[Jamie Jones]

Ok, thanks Brett.  Any scripts/details/info you guys have would be awesome.

[Brett Stahlman]

Jamie,
You can get the latest script on github:
https://github.com/bpstahlman/cac-enabled-git-setup

There's a readme there. Also, the script itself has a --help option that provides a lot of information.

Thanks, Brett S.

[Wheeler, David A]

Is anyone working to upstream the patches to curl & git patches so that they *natively* support CACs (and PIVs and other such identity systems)?

 

Who? Is there a blocker?

 

For context, I’m including older mails below.

 

--- David A. Wheeler

 

 

 

 

From: mil...@googlegroups.com [mailto:mil...@googlegroups.com] On Behalf Of Brett Stahlman

Sent: Wednesday, June 24, 2015 6:02 PM
To: mil...@googlegroups.com

[1tom...@gmail.com]

I tried running this script to build a CAC enabled git and the script appears to complete successfully but when I try to use git afterwards to clone a repo I get the error:

"fatal: curl_global_init failed".  

Curling a non-cac protected site directly with the curl built by this script fails giving this error:

curl: error initializing curl library

Has anyone else been successful with this script in cygwin?  Did you have to do anything special?  I've tried on cygwin32 and cygwin64 with identical results.  I'm looking at the curl code to see what would cause this error but so far nothing stands out.

Tom