# FreeBSD.org intrusion announced November 17th 2012



## graudeejs (Nov 17, 2012)

> Security Incident on FreeBSD Infrastructure
> From: FreeBSD Security Officer <security-officer@FreeBSD.org>
> To: FreeBSD Security <FreeBSD-security@FreeBSD.org>
> Bcc: freebsd-announce@freebsd.org, freebsd-security-notifications@FreeBSD.org
> ...



http://www.freebsd.org/news/2012-compromise.html


----------



## _martin (Nov 17, 2012)

Interesting. I didn't get how the attacker gained the access from the announcement. Did somebody "steal" that developer guy's SSH keys? 

I'm used to cvsup everything for so long .. mhm ..I think it's time for me to read the handbook again.


----------



## kpa (Nov 17, 2012)

The secret SSH keys of the developer (the ones on his client machine) leaked somehow and I guess they were not passphrase protected which in turn gives the attacker carte blanche what to do with the keys.


----------



## _martin (Nov 17, 2012)

@kpa: Yeah, I get that. I was just curious how those keys leaked in the first place.


----------



## kpa (Nov 17, 2012)

Wild guess: The keys were on a windows machine that got infected with a malware that was specifically made to snoop for Putty/SSH keys.


----------



## dclau (Nov 17, 2012)

FreeBSD developer running Windows? Darn. Girlfriend upgrade required.


----------



## AlexJ (Nov 17, 2012)

How much times did I say that CVS must be dropped because it doesn't have integrity checking?
Finally learned... the hard way...

Next prediction?
There you go http://forums.freebsd.org/showpost.php?p=114019&postcount=14
but wait... hard way is the passion...
and what would happen with FreeBSD project again if PGP key will be supplied by cracker/hacker instead of me?


----------



## Carpetsmoker (Nov 19, 2012)

The thing is, svn isn't in the base system. CVS and csup are.


----------



## gkontos (Nov 19, 2012)

Maybe it is time for the FreeBSD Foundation to consider funding a two form factor authentication system when it comes to gaining access to sensitive systems.


----------



## Crivens (Nov 19, 2012)

Carpetsmoker said:
			
		

> The thing is, svn isn't in the base system. CVS and csup are.



And it is set in stone that it keeps that way?


----------



## kpa (Nov 19, 2012)

PKGNG won't be imported into the base system, it will still become the official packaging system for FreeBSD eventually. CVS may be deleted from the base system because it exists as a port and it's not needed by any of the core utilities, not even csup.


----------



## SirDice (Nov 19, 2012)

kpa said:
			
		

> CVS may be deleted from the base system because it exists as a port and it's not needed by any of the core utilities, not even csup.


There is no CVS in the base, except csup(1).


----------



## kpa (Nov 19, 2012)

But there is 


```
fileserver ~ % which cvs
/usr/bin/cvs
fileserver ~ % uname -a
FreeBSD fileserver.houseofevil 9.1-RC2 FreeBSD 9.1-RC2 #0 r241541: Sun Oct 14 18:39:04 EEST 2012     root@fileserver.houseofevil:/usr/obj/usr/src/sys/GENERIC  amd64
fileserver ~ %
```

From src.conf(5)


```
WITHOUT_CVS
             Set to not build CVS.
```

Are you thinking of something else?


----------



## SirDice (Nov 19, 2012)

That's odd, how long has it been there? Cvsweb is still down so it's nearly impossible to track back.

But yes, we can get rid of that one. As long as csup(1) is still around (and working). At least for the time being.


----------



## Carpetsmoker (Nov 19, 2012)

cvs has been a part of FreeBSD base for as long as I can remember.


----------



## el_tedward (Nov 20, 2012)

I just wanted to be 100% clear on what this affects. In the original announcement, it says that the integrity could not be ensured for "ports compiled from trees obtained via any means other than through svn.freebsd.org or one of its mirrors."

Where does portsnap sit in the tree? Would the integrity of ports compiled from portsnap between the 19th of sep and 11th of nov be questionable in the same way as something from cvs?


----------



## el_tedward (Nov 20, 2012)

Someone on the FreeBSD mailing list pointed this out, which pretty much answers my question:
"We have also verified that the most recently-available portsnap(8) snapshot matches the ports Subversion repository"

So, I think we'll have to assume that portsnap snapshots other than the most recent one could not be verified.


----------



## chatwizrd (Nov 20, 2012)

Carpetsmoker said:
			
		

> The thing is, svn isn't in the base system. CVS and csup are.



I am assuming they will change this eventually maybe since everything is moving over to svn.


----------



## Uniballer (Nov 20, 2012)

chatwizrd said:
			
		

> I am assuming they will change this eventually maybe since everything is moving over to svn.



I am assuming that svn will never be part of the base unless a major rewrite is done to eliminate dependencies like sqlite3.


----------



## graudeejs (Nov 21, 2012)

Uniballer said:
			
		

> I am assuming that svn will never be part of the base unless a major rewrite is done to eliminate dependencies like sqlite3.



What's wrong with sqlite as dependency?
pkgng use it. And it will be part of base.


sqlite license is public domain, so no problem here.


neon however is GPL3


----------



## kpa (Nov 21, 2012)

graudeejs said:
			
		

> What's wrong with sqlite as dependency?
> pkgng use it. And it will be part of base.
> 
> 
> ...



PKGNG will stay in ports only, this has been stated numerous times by its developers. There will be a bootstrap program in the base that downloads and installs the latest ports-mgmt/pkg. The bootstrap actually exists in 9.1-RC as /usr/sbin/pkg, it's just a wrapper that does the bootstrap on first use and passes the control to /usr/local/sbin/pkg on subsequent uses. There's been suggestions to rename to bootstrap to /usr/sbin/pkg-bootstrap to avoid confusion between two binaries with the same name.


----------



## Uniballer (Nov 21, 2012)

graudeejs said:
			
		

> What's wrong with sqlite as dependency?



You might have noticed that FreeBSD base doesn't include a web browser, GUI, or relational database manager.  That's because they feel like "application" stuff, not "operating system" stuff, to operating system jocks.

Of course, I could be wrong...


----------



## Carpetsmoker (Nov 21, 2012)

sqlite is a single C source file. This can hardly be a problem. FreeBSD already includes a number of 3rd party applications & libraries.

There are other dependencies for svn which are significantly larger, like apr or bdb for example.


----------



## kpa (Nov 21, 2012)

FreeBSD developers are opposed to adding more shared libraries to the base than is absolutely necessary, that means sqlite would have to be compiled statically into programs using it much like PKGNG does.


----------



## UNIXgod (Nov 21, 2012)

Was pkgng supposed to replace the pkg_* system? or just supplement it like port(upgrade|master) are for the ports system?

Though I could see that for embedded systems it would be nice to have something like pkgng only as then one wouldn't need a separated system for administration and building. But that's what nanobsd is for.

Finally as for application development as time goes on seamless options could be created for the so called model/view/controller style development. In the case for needing a database for model being compatible with a filesystem style database like /var/db/pkg would be simple enough for pretty much anything. Non flatfile simulated rdbms unlike sqlite could be used as well for large buildsystems where concurrency may be an issues (i.e. postgresql, mysql, nosql?) ... since the command is the controller unless c hooks are exposed it's open source so anyone could build it into another application if desired... Finally for the view what is most important is the console which we already have. This could easily be brought into a 4th generation web front-end for giving access to clients who pay for such things. The gui would have been another suggestion but we aren't on ubuntu and for the current market of automation outside of browser won't be on which gfx framework anymore.

tl;dr
Unless sqlite can provide something over structuring like /var/db/pkg does or a variation of the theme pkgng should be modular and the dependency should be optional to the user to decide. 
(_Disclaimer_: I haven't used pkgng yet... If I'm completely overstepping my boundaries here by assuming how the pkgng package manager works please educate an inform me)


----------



## kpa (Nov 21, 2012)

PKGNG is meant as a complete replacement for the old pkg_* tools with some additional functionalities but it's not meant to replace ports-mgmt/portmaster or anything similar because it does not know how to build ports.


----------



## jb_fvwm2 (Nov 21, 2012)

UNIXgod said:
			
		

> Was pkgng supposed to replace the pkg_* system? or just supplement it like port(upgrade|master) are for the ports system?
> 
> Though I could see that for embedded systems it would be nice to have something like pkgng only as then one wouldn't need a separated system for administration and building. But that's what nanobsd is for.
> 
> ...



I've echoed your concerns about the deprecation of a flat-file package registry (each directory in
effect a database of its installed port, no front-end library required, easy access via command-line
tools, pipes)... in posts to the freebsd-ports lists, freebsd-current list, and in threads here, 
including real-world examples (shell tab completion into the flat-file structure ..) but AFAIK there
are more persons interested in the new default than there are persons sharing any concerns I may have
about it, at least those who have posted about it.  
  Maybe the other posts I've made (besides this one) discuss it with greater detail.


----------



## UNIXgod (Nov 21, 2012)

jb_fvwm2 said:
			
		

> I've echoed your concerns about the deprecation of a flat-file package registry (each directory in
> effect a database of its installed port, no front-end library required, easy access via command-line
> tools, pipes)... in posts to the freebsd-ports lists, freebsd-current list, and in threads here,
> including real-world examples (shell tab completion into the flat-file structure ..) but AFAIK there
> ...



Oh wow. Then I am not misinformed. Does the pkgng author/maintainer have an interest in following the `UNIX Philosophy` approach making pkgng an actual drop in replacement to pkg_* system? Even if it's for backward compatibility for third party ports or services that have scripted against pkg_* and the current package registry system.


----------



## kpa (Nov 21, 2012)

There's always the other way of looking at it and that's treating the pkg database (be it flat files or sqlite) a "black box", you're not supposed to know how it works inside. All you know is the published API and trust that the API remains compatible trough the updates.

For me the essence of UNIX way of doing things has always been "do one thing and do it well", in my opinion abstractions and data hiding are not in conflict with this philosophy.


----------



## jb_fvwm2 (Nov 22, 2012)

To counterpoint, "many ways of doing things, since this is unix not ..."  ( I read a post which postulated that putting all the program parameters in the registry (windows) is a 
shortsighted method of implementing something rc.d-like. ... I often think of that analogy when pondering this issue.)


----------

