maemo.org - Talk

maemo.org - Talk (https://talk.maemo.org/index.php)
-   Maemo 5 / Fremantle (https://talk.maemo.org/forumdisplay.php?f=40)
-   -   Marmistrz's failed devel package - unexpected results/conclusions (https://talk.maemo.org/showthread.php?t=83948)

szopin 2012-04-28 15:18

Re: Marmistrz's failed devel package - unexpected results/conclusions
 
Install FM Radio latest version from devel. Click on icon... nothing happens. Probably many more packages have such behaviour (maybe PR 1.2 app?) but on WIN I would instantly start an AV soft and download another to perform a check, just to be sure (which will never be oh well). -devel allowing apps to run as superuser is just another vector of attack. N900 is super easy for malicious devs to attack, only thing that is helping is lack in numbers (but this as security through obscurity is dumb defense at best)

Ken-Young 2012-04-28 15:27

Re: Marmistrz's failed devel package - unexpected results/conclusions
 
Quote:

Originally Posted by szopin (Post 1198681)
[...] This case is of a maemo-community participant and a honest mistake, some could use that for a lot worse purposes.
Is this issue for council to decide/fix? Nokia? Community?
[...]

This is part of the price we pay for having a broken QA process. Since many packages languish for months in Extras Testing, people have started downloading from the more risky repositories, because they are the only ones with new packages.

marmistrz 2012-04-28 18:59

Re: Marmistrz's failed devel package - unexpected results/conclusions
 
Quote:

Originally Posted by Ken-Young (Post 1198710)
This is part of the price we pay for having a broken QA process. Since many packages languish for months in Extras Testing, people have started downloading from the more risky repositories, because they are the only ones with new packages.

Indeed, it's what's the problem. I use extras-devel myself, continuously enabled, but have at least apt-pinning done.

javispedro 2012-04-28 19:15

Re: Marmistrz's failed devel package - unexpected results/conclusions
 
/me grabs popcorn.

In any case,
Never apt-get upgrade or dist-upgrade with extras-devel enabled. It was already common knowledge in 2009... seems that this has to be periodically refreshed...

There has been many similar situations to this one. Someone packages some "dependencies" and all those who apt-get upgrade from extras-devel get bricked.
And packages that brick the device are the easy ones. There are much more subtle issues such as losing audio, codec support, general slowness or battery issues....

So, never upgrade with extras-devel enabled.


Quote:

Originally Posted by szopin (Post 1198709)
(but this as security through obscurity is dumb defense at best)

Please explain where the obscurity is. Every package source code is publicly readable for you to read.

szopin 2012-04-28 19:22

Re: Marmistrz's failed devel package - unexpected results/conclusions
 
Static libs inclusions, or are they blocked by autobuilder?

javispedro 2012-04-28 19:26

Re: Marmistrz's failed devel package - unexpected results/conclusions
 
Quote:

Originally Posted by szopin (Post 1198781)
Static libs inclusions, or are they blocked by autobuilder?

The autobuilder will not block virtually anything except for a few trivial cases. But you can still see the build process (which is the point here).

szopin 2012-04-28 19:27

Re: Marmistrz's failed devel package - unexpected results/conclusions
 
And you making a point this was common knowledge in 2009, just enforces current lack of that common knowledge. While you enjoy your popcorn, most 2012 people just heard devel is dangerous/untrustworthy... bon apetite

szopin 2012-04-28 19:29

Re: Marmistrz's failed devel package - unexpected results/conclusions
 
Quote:

Originally Posted by javispedro (Post 1198786)
The autobuilder will not block virtually anything except for a few trivial cases. But you can still see the build process (which is the point here).

Trivial maybe in 2009, but now future life of N900 depends on them (gcc/libstdc++...). Seeing a build process of something that includes malicious .so helps how exactly?

Estel 2012-04-28 19:47

Re: Marmistrz's failed devel package - unexpected results/conclusions
 
@javispedro
Can't fully agree. It's not the case of apt-get upgrade or dist-upgrade - package mentioned in first post is a dependency of many other packages, so, even upgrading "theoretically" safe thing like NES or PS emulator (which one agrees to download from -devel, due to trust for developer), people will get broken system core package, without fault on side from developer of mentioned emulator!

Clearly, it's marmistrz fault mostly, but neither should it be allowed by repositories. another question is why sometimes it works like that, and for some package, such trick isn't possible? Smells very buggy.

/Estel

javispedro 2012-04-28 20:05

Re: Marmistrz's failed devel package - unexpected results/conclusions
 
Note that the popcorn comes from the fact that we are going to repeat (again) a discussion that has been made quite a few times, that usually gets little positive results (if any).

Quote:

Originally Posted by szopin (Post 1198789)
Trivial maybe in 2009, but now future life of N900 depends on them (gcc/libstdc++...).

I mean trivial as in "script that is doing that check is a few chars long". And buggy, as Estel commented.

Quote:

Originally Posted by szopin (Post 1198789)
Seeing a build process of something that includes malicious .so helps how exactly?

In that you WON'T install it?



Quote:

Originally Posted by Estel (Post 1198796)
Can't fully agree. It's not the case of apt-get upgrade or dist-upgrade - package mentioned in first post is a dependency of many other packages, so, even upgrading "theoretically" safe thing like NES or PS emulator (which one agrees to download from -devel, due to trust for developer), people will get broken system core package, without fault on side from developer of mentioned emulator!

They _won't_ as long as they don't use apt-get upgrade.

You can manage to bork a -dev package so that it actually causes a dep on the broken version, and this is actually the default case if you don't use e.g. shlibs.
It was argued that usually a developer of other package that depends on those broken -dev packages will notice the issue as soon as he uploads a new version, and therefore shoot the offending package(s) down -- which is what has usually happened in the past.

OTOH, private repos: http://repo.pub.meego.com/home%3a/


All times are GMT. The time now is 23:25.

vBulletin® Version 3.8.8