Pierre schrieb
Nur am das richtig zu stellen: Dieses Projekt betrifft das jetzige Arch nicht. Wir ändern an unserer Philosophie nichts. Das besagte Projekt ist von einigen Nutzern ins Leben gerufen worden und basiert auf Arch.
Kannst du das vielleicht ein wenig erleutern?
Meine Erfahrungen mit Archlinux sind folgende. Letzte Nacht wurden auf den Opera Spiegelservern die neue Version stabile 9.26 hochgeladen.
Change Log
http://www.opera.com/docs/changelogs/linux/926/
Changelog for Opera 9.26 for Linux
Opera 9.26 for Linux is available for download.
Release Notes
This release is a recommended security and stability upgrade. See the Security section for additional information.
Changes Since Opera 9.25
Security
Fixed an issue where simulated text inputs could trick users into uploading arbitrary files, as reported by Mozilla. See our advisory.
Image properties can no longer be used to execute scripts, as reported by Max Leonov. See our advisory.
Fixed an issue where the representation of DOM attribute values could allow cross site scripting, as reported by Arnaud.lb. See our advisory.
Miscellaneous
Fixed a stability issue found in Opera 9.0 to 9.25, when Opera connects securely to Windows Server 2008 or other servers supporting the TLS Certificate Status extension.
Additional stability fixes.
also habe ich mir ganz schnell ein PKGBUILD gebaut
# Modified by Uwe Vogt for the repositories <jada@usalug.net>
# changes
# sed 's|/usr/X11R6/lib/mozilla/plugins=1|/opt/mozilla/lib/plugins=1|' -i ini/pluginpath.ini || return 1
# to New
# sed 's|/usr/X11R6/lib/mozilla/plugins=1|/usr/lib/mozilla/plugins=1|' -i ini/pluginpath.ini || return 1
pkgname=opera
pkgver=9.26
pkgrel=2
pkgdesc="The Opera web browser"
url="http://www.opera.com/"
depends=(qt3)
license=('custom:opera')
arch=('i686')
source=(http://ftp.opera.com/pub/opera/linux/926/final/en/i386/shared/opera-9.26-20080218.6-shared-qt.i386-en.tar.bz2
opera.desktop)
options=('force')
build() {
cd ${startdir}/src/opera-9.26-20080218.6-shared-qt.i386-en-698
sed 's|/usr/X11R6/lib/mozilla/plugins=1|/usr/lib/mozilla/plugins=1|' -i ini/pluginpath.ini || return 1
./install.sh DESTDIR=${startdir}/pkg
install -D -m 644 ${startdir}/src/opera.desktop ${startdir}/pkg/usr/share/applications/opera.desktop
install -D -m 644 LICENSE ${startdir}/pkg/usr/share/licenses/opera/license.txt
}
md5sums=('e29856b248f503b5a724c7c548c42483'
'f99bef1a9200abe5a5cda78665cddc84')
}
dieses dann an dieses dann an die Developmer geschickt. Nun nimmt dieses erst einmal seinen bürokratischen Weg.
Eine Antwort erhielt ich schon
There is no reason to send these things to me. We have a bug tracker
for this - it is MUCH easier to manage than my personal email box.
I have CC'd tomk on here, as he is the last one who built opera, so
perhaps he may do it again.
Going forward, please enter items like this in the bug tracker.
Thanks,
Aaron
Nun mache ich mir meine Gedanken, wie kann man sowas schneller abwickeln.
Es war ja nun nicht die feine Art von Mozilla, 24 Stunden nach dem sie Opera informiert hatten diesen Bug öffentlich zu machen 😉 Nun sollte man aber zusehen das dieses Sicherheitsloch so schnell wie möglich geschlossen ist.
Gleichzeitig sehe ich das z.B. Seamonkey unter Archlinux weiter mit den als kritisch eingstuften Sicherheitsrisiken vorhanden ist.
Was ich also unter diesen Project verstehe ist eine Art Taskforce Team die sich darauf beschränkt Sicherheitslöcher die als kritisch :High" eingestuft sind in einen Zeitraum von unter 24 Stunden zu schliessen und nicht warten muss bis der eigendliche Developmer die Zeit hat sich der Sache anzunehmen.