Active Topics
-
Maemo repository (5)
to Community by dredlok706 - 1 day, 18 hrs ago -
Re-commissioning N9 in 2018 (127)
to MeeGo / Harmattan by smatkovi - 1 day, 21 hrs ago -
Porting apps to Leste (41)
to Maemo 7 / Leste by Arno_11 - 2 days, 15 hrs ago -
List of well performing apps on Leste (33)
to Maemo 7 / Leste by teroyk - 2 days, 23 hrs ago -
N900 is not recognizable on any of my devices (windows 10,7, xp) What can I do? (1)
to Nokia N900 by nieldk - 4 days, 3 hrs ago - more...
szopin |
2012-04-28
, 15:18
|
|
Posts: 2,076 |
Thanked: 3,268 times |
Joined on Feb 2011
|
#11
|
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)
| The Following 2 Users Say Thank You to szopin For This Useful Post: | ||
 |
|
2012-04-28
, 15:27
|
|
Posts: 387 |
Thanked: 1,700 times |
Joined on Feb 2010
@ Cambridge, MA, USA
|
#12
|
Originally Posted by szopin
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.
[...] 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?
[...]
| The Following 8 Users Say Thank You to Ken-Young For This Useful Post: | ||
|
|
2012-04-28
, 18:59
|
|
Posts: 3,328 |
Thanked: 4,476 times |
Joined on May 2011
@ Poland
|
#13
|
Originally Posted by Ken-Young
Indeed, it's what's the problem. I use extras-devel myself, continuously enabled, but have at least apt-pinning done.
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.
 |
|
2012-04-28
, 19:15
|
|
Posts: 2,355 |
Thanked: 5,249 times |
Joined on Jan 2009
@ Barcelona
|
#14
|
/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.
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.
Originally Posted by szopin
Please explain where the obscurity is. Every package source code is publicly readable for you to read.
(but this as security through obscurity is dumb defense at best)
| The Following 2 Users Say Thank You to javispedro For This Useful Post: | ||
|
|
2012-04-28
, 19:22
|
|
Posts: 2,076 |
Thanked: 3,268 times |
Joined on Feb 2011
|
#15
|
Static libs inclusions, or are they blocked by autobuilder?
|
|
2012-04-28
, 19:26
|
|
Posts: 2,355 |
Thanked: 5,249 times |
Joined on Jan 2009
@ Barcelona
|
#16
|
Originally Posted by szopin
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).
Static libs inclusions, or are they blocked by autobuilder?
|
|
2012-04-28
, 19:27
|
|
Posts: 2,076 |
Thanked: 3,268 times |
Joined on Feb 2011
|
#17
|
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
| The Following 2 Users Say Thank You to szopin For This Useful Post: | ||
|
|
2012-04-28
, 19:29
|
|
Posts: 2,076 |
Thanked: 3,268 times |
Joined on Feb 2011
|
#18
|
Originally Posted by javispedro
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?
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).
| The Following 2 Users Say Thank You to szopin For This Useful Post: | ||
 |
|
2012-04-28
, 19:47
|
|
Posts: 5,028 |
Thanked: 8,613 times |
Joined on Mar 2011
|
#19
|
@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
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
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
| The Following User Says Thank You to Estel For This Useful Post: | ||
|
|
2012-04-28
, 20:05
|
|
Posts: 2,355 |
Thanked: 5,249 times |
Joined on Jan 2009
@ Barcelona
|
#20
|
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).
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/
Originally Posted by szopin
I mean trivial as in "script that is doing that check is a few chars long". And buggy, as Estel commented.
Trivial maybe in 2009, but now future life of N900 depends on them (gcc/libstdc++...).
Originally Posted by szopin
In that you WON'T install it?
Seeing a build process of something that includes malicious .so helps how exactly?
Originally Posted by Estel
They _won't_ as long as they don't use apt-get upgrade.
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!
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/
| The Following 5 Users Say Thank You to javispedro For This Useful Post: | ||