Todd Zullinger wrote:
By policy, there are things that rpm scriptlets should not do. But if
you created an rpm which had a %post section containing rm -rf /, rpm
would run it AFAIK.
Oh! 8-O
I wonder how easy it is to create a rootkit/trojan horse/whatever
and get it loaded on Fedora users'
Stanisław T. Findeisen wrote:
Really? Have you seen a list telling you who reviewed which package
before it got signed with Fedora key?
Probably there are lots of packages reviewed by their authors only?
Review and signing are two different processes. Every single new package
has to go
Rahul Sundaram wrote:
Probably there are lots of packages reviewed by their authors only?
Review and signing are two different processes. Every single new package
has to go through a review process as outlined in
http://fedoraproject.org/wiki/Packaging/ReviewGuidelines
Signing a package is
Stanisław T. Findeisen wrote:
Rahul Sundaram wrote:
Probably there are lots of packages reviewed by their authors only?
Review and signing are two different processes. Every single new package
has to go through a review process as outlined in
Rahul Sundaram wrote:
You missed that the review guidelines has a source check as well. Read
it in detail.
Where's that, sorry?
STF
===
http://eisenbits.homelinux.net/~stf/
OpenPGP: 9D25 3D89 75F1 DF1D F434 25D7 E87F A1B9
Rahul Sundaram wrote:
Stanisław T. Findeisen wrote:
Well, it looks that those review guidelines cover mostly
administrative/legal issues. It looks that no one cares about the
source code.
You missed that the review guidelines has a source check as well.
Read it in detail.
While the review
Todd Zullinger wrote:
Rahul Sundaram wrote:
Stanisław T. Findeisen wrote:
Well, it looks that those review guidelines cover mostly
administrative/legal issues. It looks that no one cares about the
source code.
You missed that the review guidelines has a source check as well.
Read it in
Rahul Sundaram wrote:
Todd Zullinger wrote:
While the review guidelines do make sure that the source code
matches upstream¹, that doesn't ensure that upstream doesn't have
backdoors, holes, malicious content, etc.
That's a totally different question IMO.
No doubt. I was only mentioning
Rahul Sundaram wrote:
While the review guidelines do make sure that the source code matches
upstream¹, that doesn't ensure that upstream doesn't have backdoors,
holes, malicious content, etc.
That's a totally different question IMO. We at the distribution level
can only check whether there is
Todd Zullinger wrote:
And, of course, on top of compiler options and firewalls, SELinux is
one more layer that is added to protect against problems in upstream
code. If upstream code has some hole that tries to mail off
/etc/passwd somewhere, this is very likely to be denied by SELinux.
And
Stanisław T. Findeisen wrote:
Okay is there any software written specifically for Fedora? KDE gadgets,
or such?
If so, then I guess we should monitor it at the distribution level.
Much of the software originally written for Fedora are used by other
distributions as well like NetworkManager
Stanisław T. Findeisen wrote:
SELinux will not help you more if it gets overwritten/rootkited by
malicious RPM package (for instance during the install process).
But then we're back to the question of how such a malicious rpm would
get onto your system. Someone doing such a thing in %post
Stanisław T. Findeisen wrote:
Todd Zullinger wrote:
And, of course, on top of compiler options and firewalls, SELinux is
one more layer that is added to protect against problems in upstream
code. If upstream code has some hole that tries to mail off
/etc/passwd somewhere, this is very likely
On Thu, 2009-04-02 at 15:22 +0200, Stanisław T. Findeisen wrote:
Todd Zullinger wrote:
And, of course, on top of compiler options and firewalls, SELinux is
one more layer that is added to protect against problems in upstream
code. If upstream code has some hole that tries to mail off
Stanisław T. Findeisen wrote:
Todd Zullinger wrote:
And, of course, on top of compiler options and firewalls, SELinux is
one more layer that is added to protect against problems in upstream
code. If upstream code has some hole that tries to mail off
/etc/passwd somewhere, this is very likely
On Thu, 2009-04-02 at 10:12 -0500, Mikkel L. Ellertson wrote:
if you want to be safe, you should only use code you have
written/inspected yourself, compiled on a compiler that you
have written yourself.
And that includes the OS, too.
Real programmers compile on paper, and tap in the hex...
Tim wrote:
On Thu, 2009-04-02 at 10:12 -0500, Mikkel L. Ellertson wrote:
if you want to be safe, you should only use code you have
written/inspected yourself, compiled on a compiler that you
have written yourself.
And that includes the OS, too.
Definitely!
Real programmers compile on
On Thu, 2009-04-02 at 10:12 -0500, Mikkel L. Ellertson wrote:
Then again, if you want to be safe, you should only use code you
have written/inspected yourself, compiled on a compiler that you
have written yourself. After all, it was proven that you could imbed
code in the compiler that would
What does the process of installing new RPM package look like? There are
some commands that such package is allowed to execute, right?
What are RPMs allowed to do, and what is forbidden? Is there any control
layer at all in the package manager, or is the control (e.g., during
package install)
Stanisław T. Findeisen wrote:
What does the process of installing new RPM package look like? There
are some commands that such package is allowed to execute, right?
By policy, there are things that rpm scriptlets should not do. But if
you created an rpm which had a %post section containing rm
20 matches
Mail list logo
