Comments for coupleprogramming

Comment on rulegenerator for firewalls or what I’ve been up to by constanze

constanze — Tue, 01 Mar 2011 18:28:48 +0000

Hi Pavel,
if you ask for it, you’ll get one :). I’ll try to get around to it this weekend.

Comment on rulegenerator for firewalls or what I’ve been up to by Pavel

Pavel — Tue, 01 Mar 2011 00:42:19 +0000

and where’s the ebuild? :wink: thanks for releasing this, i’m definitely going to play around with it!

Comment on rulegenerator for firewalls or what I’ve been up to by constanze

constanze — Sun, 27 Feb 2011 18:40:29 +0000

That’s actually a good idea. Internally the the rules are handled independently of the output style. The conversion to the output style only happens in the __str__ method. So it wouldn’t be difficult to generate a generic output.
The original idea was that users could just copy the output to their pf.conf/add the rules to netfilter.

Comment on rulegenerator for firewalls or what I’ve been up to by Will B.

Will B. — Sun, 27 Feb 2011 18:16:18 +0000

Here-s a suggetion – how about creating an output that’s more generic (e.g. some type of XML)? That will allow for “plugins” that consume this and converts it to a rulebase firewall type?

Comment on The state of Scala on Gentoo by knecht

knecht — Sun, 23 Jan 2011 12:15:40 +0000

I’m an java developer and also think scala is an attraction i’d like to have it in portage :D

Thanks for your post!

Comment on The state of Scala on Gentoo by Drybone

Drybone — Sat, 22 Jan 2011 17:42:51 +0000

The issue is that Scala comes with its own portable package management and versioning utility (scalabaz). That tools of course is nowhere near the flexibility and power of portage, but you can already just install Scala into unprivileged account, and it just works (but if you ask me if Scala developers should have wasted there efforts for yet another mediocre package management software – my answer is definitelly no, but it’s a bit too late to discuss the point as scalabaz is already there). So no wonder noone currently looks at Scala portage packages as a priority. There is only one area where the packages will be immediately (and immensely) useful: compiling the all-fresh version from a source code repository, obeying all the dependencies and so on.

The problem is, it turns out that right of today (20110122) there are no good stable versions available at all. In particular, the rather critical Scala runtime library bugs #3886 and #3984 were fixed after the last stable version of 2.8.1, and as there are no plans releasing 2.8.2, we all currently wait for 2.9.0 as a stable and production quality version (with improved compiler performance, and number of other tasty improvements). In the mean time, if you are developing non-trivial Scala programs you are most likely to hit one of those bugs, and you are just safer to use a recent nightly build, which in practical terms means you already resorted to using scalabaz.

In spite of that, factually all Scala versions could be removed from portage for now. 1.2 for sure, as you don’t even find such ancient version on scala web site archive; 2.7.7 should be gone for good too, as that’s version released before the 2.8.0 API stabilization, and lacks the modern Scala Collections API – perhaps one of the powerful element of the Scala techology (to the same scale as the powerful language syntax, or its actors or xml libraries). So just drop 2.7.7 now, to avoid messing with incompatibilities few weeks down the road.

Comment on The state of Scala on Gentoo by ntoythi

ntoythi — Sat, 22 Jan 2011 15:15:47 +0000

Just to clarify: this posting is not from constanze but got aggregated to planet.gentoo.org because of a wrong aggregation-url. Sorry for the inconvenience.

Comment on Progress Report #9 for POSIX-Capabilities Project by constanze

constanze — Mon, 30 Aug 2010 17:24:47 +0000

@jim
If my project will be included in the tree, it would mean for you, that you could use file-based caps instead of setuid with certain, patched applications.
In other words: File-based caps allow you to grant certain (special) rights instead of the now used setuid-bit.
If the setuid-bit is set an application is executed with rights of the _owner_ and not executer (which is the normal case). If the owner is root, which is the case with most setuid-apps, the executer has full root privileges with this app. That means a privilege escalation is possible, if the program has flaws.
In short with caps, the potential attacker can only gain partial permissions (like permission to use a raw_socket), instead of full root.

I hope your questions are answered :).

Comment on Progress Report #9 for POSIX-Capabilities Project by rullzer

rullzer — Sun, 15 Aug 2010 18:22:41 +0000

I enjoyed reading your updates and hope you will continue to work on this since this could mean huge security improvements!

Keep it up!

Comment on Progress Report #9 for POSIX-Capabilities Project by Jim

Jim — Thu, 12 Aug 2010 19:57:26 +0000

I’ve been following the GSoC projects via the planet-larry feed, but I’m still not 100% on what your project means for the average user.

Care to write a “what this means for you” post? :)