Re: Please rebuild all ports that depend on PNG
On 02/06/2012 23:53, Chad Perrin wrote: In fact, many of the weaknesses of SSL systems as currently designed could be obviated by having used OpenPGP as the basis of the system rather than creating this whole PKI system for the sole purpose of making corporate CAs seem necessary as imaginary authorities who claim to be able to provide special security guarantees. There's very interesting work going on at the moment about publishing SSL keys or fingerprints via DNSSEC-secured DNS. See: http://www.internetsociety.org/articles/dane-taking-tls-authentication-next-level-using-dnssec https://tools.ietf.org/html/draft-ietf-dane-protocol-21 So anyone in control of a DNS domain and capable of enabling DNSSEC can issue themselves authenticable TLS certificates without having to line the pockets of the CAs. Server-side, support for the TLSA RR type this is all based on was added to the last update of BIND, which hit stable on Friday. Client side, support is available in Chrome and FireFox by various means. Other than throwing a big spanner into the works for the whole CA business model, this moves the responsibility for identifying the site owner from the CA to the DNS Registrar[*]. While the normal mode will be to have authenticity assured from the root, this does in principle permit any number of DLV-style trust anchors. Whether that can be parlayed into PGP style web-of-trust is an interesting question. Cheers, Matthew [*] It's not hard to convince a DNS Registrar that you should have the rights to a domain name -- you just keep giving them money. -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Re: Please rebuild all ports that depend on PNG
On Sun, Jun 03, 2012 at 08:14:40AM +0100, Matthew Seaman wrote: On 02/06/2012 23:53, Chad Perrin wrote: In fact, many of the weaknesses of SSL systems as currently designed could be obviated by having used OpenPGP as the basis of the system rather than creating this whole PKI system for the sole purpose of making corporate CAs seem necessary as imaginary authorities who claim to be able to provide special security guarantees. There's very interesting work going on at the moment about publishing SSL keys or fingerprints via DNSSEC-secured DNS. See: http://www.internetsociety.org/articles/dane-taking-tls-authentication-next-level-using-dnssec https://tools.ietf.org/html/draft-ietf-dane-protocol-21 So anyone in control of a DNS domain and capable of enabling DNSSEC can issue themselves authenticable TLS certificates without having to line the pockets of the CAs. Server-side, support for the TLSA RR type this is all based on was added to the last update of BIND, which hit stable on Friday. Client side, support is available in Chrome and FireFox by various means. Other than throwing a big spanner into the works for the whole CA business model, this moves the responsibility for identifying the site owner from the CA to the DNS Registrar[*]. While the normal mode will be to have authenticity assured from the root, this does in principle permit any number of DLV-style trust anchors. Whether that can be parlayed into PGP style web-of-trust is an interesting question. Hey! thats pretty cool. Thanks for the information Matt. -- - (2^(N-1)) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Please rebuild all ports that depend on PNG
WOW - is the realy no other posibillity for PNG than rebuild all depended Ports? It is al lot! it will cost me three days Realy no other possibility?! Information for png-1.4.11: Required by: ImageMagick-6.7.7.0 Terminal-0.4.8 Thunar-1.4.0 akonadi-1.7.2 ark-4.8.3 audacious-3.2.2 audacious-plugins-3.2.2_1 cairo-1.10.2_3,2 cairomm-1.10.0 clementine-player-1.0.0_4 cm-super-0.3.4_3 consolekit-0.4.3 cups-base-1.5.2 cups-image-1.5.2 cups-pstoraster-8.15.4_6 dbus-qt3-0.70_5 dconf-0.5.1_3 de-kde-l10n-4.8.3 de-libreoffice-3.5.2 doxygen-1.8.0 dvipsk-tetex-5.95a_5 easytag-2.1.7 emacs-24.0.93.107364,1 ffmpeg-0.7.12_1,1 filelight-4.8.3 firefox-12.0,1 gconf2-2.32.0_2 gd-2.0.35_7,1 gdk-pixbuf-2.23.5_2 geeqie-1.0_4 gegl-0.1.8_3 ghostscript8-8.71_8 gimp-app-2.6.12,1 gnome-icon-theme-2.31.0_1 gnome-keyring-2.32.1_1 gnome-mount-0.8_9 gnome-vfs-2.24.4 gpac-libgpac-0.4.5_5,1 graphviz-2.28.0 grip-3.3.1_4 gstreamer-0.10.35 gstreamer-ffmpeg-0.10.13 gstreamer-plugins-0.10.35_1,3 gstreamer-plugins-a52dec-0.10.18,3 gstreamer-plugins-bad-0.10.22,3 gstreamer-plugins-core-0.10_12 gstreamer-plugins-dts-0.10.22,3 gstreamer-plugins-dvd-0.10.18_1,3 gstreamer-plugins-flac-0.10.30,3 gstreamer-plugins-gio-0.10.35,3 gstreamer-plugins-good-0.10.30,3 gstreamer-plugins-libpng-0.10.30,3 gstreamer-plugins-mad-0.10.18,3 gstreamer-plugins-mp3-0.10.0_1 gstreamer-plugins-ogg-0.10.35,3 gstreamer-plugins-pango-0.10.35,3 gstreamer-plugins-soup-0.10.30,3 gstreamer-plugins-theora-0.10.35,3 gstreamer-plugins-ugly-0.10.18_1,3 gstreamer-plugins-vorbis-0.10.35,3 gstreamer-plugins-xvid-0.10.22,3 gtk-2.24.6_1 gtk-engines2-2.20.2 gtk-update-icon-cache-2.24.6 gtk-xfce-engine-3.0.0 gtkimageview-1.6.4_2 gtkmm-2.24.2 gvfs-1.6.6_2 hal-0.5.14_19 hupnp-1.0.0 icons-tango-0.8.90_1 icons-tango-extras-0.1.0_4 jbig2dec-0.11 kactivities-4.8.3 kate-4.8.3 kaudiocreator-1.2.90_4 kcalc-4.8.3 kcharselect-4.8.3 kde-baseapps-4.8.3 kde-runtime-4.8.3 kde-wallpapers-4.8.3 kde-workspace-4.8.3 kdelibs-4.8.3 kdemultimedia-4.8.3 kdepimlibs-4.8.3 kdetoys-4.8.3 kdf-4.8.3 kfloppy-4.8.3 kgpg-4.8.3 kio-upnp-ms-1.0.0.g20110808_1 konsole-4.8.3 kremotecontrol-4.8.3 ksnapshot-4.8.3 ktimer-4.8.3 kwallet-4.8.3 lensfun-0.2.5_2 libbonoboui-2.24.4 libcanberra-0.28_1 libdbusmenu-qt-0.9.2 libdmtx-0.7.4_1 libexo-0.8.0 libglade2-2.6.4_4 libgnome-2.32.0 libgnome-keyring-2.32.0_1 libgnomecanvas-2.30.3 libgnomeui-2.24.4 libgsf-1.14.21 libkate-0.4.1 libkipi-4.8.3 libkonq-4.8.3 liblastfm-0.3.3_2 libmcs-0.7.2_1 libnotify-0.7.3_1 libqrencode-3.3.1 libreoffice-3.5.2_2 librsvg2-2.34.1 libsoup-gnome-2.34.3_1 libspectre-0.2.6 libvisio-0.0.16 libwnck-2.30.6 libwpd-0.9.4 libwpg-0.2.1 libwps-0.2.6 libxfce4gui-4.10.0 libxfce4menu-4.10.0 libxine-1.2.1 libzvbi-0.2.33_3 linux-opera-11.62 m17n-lib-1.6.3 mousepad-0.2.16_9 mplayer-1.0.r20120322_1 netpbm-10.35.84_1 okular-4.8.3 open-motif-2.3.3 orage-4.8.3 pango-1.28.4 pangomm-2.28.2 phonon-4.6.0 phonon-gstreamer-4.6.0 plasma-applet-simpleweatherforecast-1.3_3 policykit-gnome-0.9.2_5 polkit-0.99 polkit-kde-0.99.0_2 polkit-qt-0.103.0 poppler-0.18.4 poppler-glib-0.18.4_1 poppler-qt4-0.18.4 prison-1.0 qimageblitz-0.0.6 qt-3.3.8_13 qt4-assistant-4.8.1 qt4-declarative-4.8.1 qt4-designer-4.8.1 qt4-gui-4.8.1 qt4-help-4.8.1 qt4-help-tools-4.8.1 qt4-iconengines-4.8.1 qt4-imageformats-4.8.1 qt4-inputmethods-4.8.1 qt4-linguist-4.8.1 qt4-opengl-4.8.1 qt4-pixeltool-4.8.1 qt4-qdbusviewer-4.8.1 qt4-qt3support-4.8.1 qt4-qvfb-4.8.1 qt4-scripttools-4.8.1 qt4-svg-4.8.1 qt4-webkit-4.8.1 qtscriptgenerator-0.2.0 qzeitgeist-0.8.0 rawstudio-2.0_1 rawtherapee-4.0.8 sdl_image-1.2.12 seamonkey-2.9.1 squeeze-0.2.3_3 strigi-0.7.7_1 superkaramba-4.8.3 sweeper-4.8.3 teTeX-3.0_5 teTeX-base-3.0_22 thunar-vfs-1.2.0_1 ufraw-0.18_2 upower-0.9.7 vigra-1.7.1_3 vlc-1.1.13_9,3 vorbis-tools-1.4.0_2,3 vte-0.26.2_1 webp-0.1.3 x264-0.123.2189_1 xcursorgen-1.0.4 xdvik-tetex-22.84.16_3 xf86-input-keyboard-1.6.1 xf86-input-mouse-1.7.1 xf86-video-ati-6.14.3_1 xfce-4.10 xfce4-appfinder-4.10.0 xfce4-artwork-0.0.4_11 xfce4-conf-4.10.0 xfce4-desktop-4.10.0 xfce4-mixer-4.8.0_1 xfce4-notifyd-0.2.2_1 xfce4-panel-4.10.0 xfce4-print-4.6.1_7 xfce4-session-4.10.0 xfce4-settings-4.10.0 xfce4-tumbler-0.1.25 xfce4-utils-4.8.3_3 xfce4-weather-plugin-0.7.4_2 xfce4-wm-4.10.0 xfce4-wm-themes-4.10.0 xorg-apps-7.5.2 xorg-server-1.7.7_5,1 xvattr-1.3_7 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Please rebuild all ports that depend on PNG
On 02/06/2012 07:59, Heino Tiedemann wrote: WOW - is the realy no other posibillity for PNG than rebuild all depended Ports? It is al lot! it will cost me three days Realy no other possibility?! You need to rebuild all the ports that install binaries that link against libpngNN.so.NN. That is actually a subset of the ports that depend on graphics/png -- unfortunately it takes some effort to identify precisely what does need rebuilding. There is the pkg_libchk script (which is part of sysutils/bsdadminscripts) that can help. However all ports that are known to depend on graphics/png have had portrevision bumps even when this makes no difference what so ever -- such as for ports that install pure perl code -- so the normal process of maintaining your ports will eventually result in your rebuilding everything in your list. Use pkg_libchk to prioritise the ports that really need to be rebuilt. Also, when upgrading graphics/png remember to use 'portmaster -w' or equivalent to preserve a copy of the old shlib, otherwise a lot of your apps will stop working for the duration of the upgrade session. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Re: Please rebuild all ports that depend on PNG
Matthew Seaman wrote: On 02/06/2012 07:59, Heino Tiedemann wrote: WOW - is the realy no other posibillity for PNG than rebuild all depended Ports? It is al lot! it will cost me three days Realy no other possibility?! You need to rebuild all the ports that install binaries that link against libpngNN.so.NN. That is actually a subset of the ports that depend on graphics/png -- unfortunately it takes some effort to identify precisely what does need rebuilding. There is the pkg_libchk script (which is part of sysutils/bsdadminscripts) that can help. However all ports that are known to depend on graphics/png have had portrevision bumps even when this makes no difference what so ever -- such as for ports that install pure perl code -- so the normal process of maintaining your ports will eventually result in your rebuilding everything in your list. Use pkg_libchk to prioritise the ports that really need to be rebuilt. Also, when upgrading graphics/png remember to use 'portmaster -w' or equivalent to preserve a copy of the old shlib, otherwise a lot of your apps will stop working for the duration of the upgrade session. And maybe you can try to use EXPLICIT_PACKAGE_DEPENDS=true in make.conf to record only direct dependencies, so next time you can easily list those ports by pkg_info -R png-1.4.11 Miroslav Lachman ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Please rebuild all ports that depend on PNG
Realy no other possibility?! You need to rebuild all the ports that install binaries that link against libpngNN.so.NN. That is actually a subset of the ports that depend on graphics/png -- unfortunately it takes some effort to identify precisely what does need rebuilding. There is the pkg_libchk script (which is part of sysutils/bsdadminscripts) that can help. ... Use pkg_libchk to prioritise the ports that really need to be rebuilt. Lawrence Stewart's convenient script can be used with portmaster to perform this kind of update: https://lauren.room52.net/hg/scripts/raw-file/tip/libdepend/libdepend.sh b. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Please rebuild all ports that depend on PNG
On Sat, 2 Jun 2012 11:07:28 -0400 b. f. articulated: Realy no other possibility?! You need to rebuild all the ports that install binaries that link against libpngNN.so.NN. That is actually a subset of the ports that depend on graphics/png -- unfortunately it takes some effort to identify precisely what does need rebuilding. There is the pkg_libchk script (which is part of sysutils/bsdadminscripts) that can help. ... Use pkg_libchk to prioritise the ports that really need to be rebuilt. Lawrence Stewart's convenient script can be used with portmaster to perform this kind of update: https://lauren.room52.net/hg/scripts/raw-file/tip/libdepend/libdepend.sh I am receiving a: This Connection is Untrusted warning from Firefox when I attempt to connect to that URL. It is probably harmless; however, it certainly doesn't instill confidence is someone viewing the site for the first time. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Please rebuild all ports that depend on PNG
On Jun 2, 2012 5:27 PM, Jerry je...@seibercom.net wrote: On Sat, 2 Jun 2012 11:07:28 -0400 b. f. articulated: Realy no other possibility?! You need to rebuild all the ports that install binaries that link against libpngNN.so.NN. That is actually a subset of the ports that depend on graphics/png -- unfortunately it takes some effort to identify precisely what does need rebuilding. There is the pkg_libchk script (which is part of sysutils/bsdadminscripts) that can help. ... Use pkg_libchk to prioritise the ports that really need to be rebuilt. Lawrence Stewart's convenient script can be used with portmaster to perform this kind of update: https://lauren.room52.net/hg/scripts/raw-file/tip/libdepend/libdepend.sh I am receiving a: This Connection is Untrusted warning from Firefox when I attempt to connect to that URL. It is probably harmless; however, it certainly doesn't instill confidence is someone viewing the site for the first time. It just means he hasn't bought a certificate- no less trustworthy than vanilla (non-SSL) http. Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Please rebuild all ports that depend on PNG
On Sat, 2 Jun 2012 17:34:59 +0100 Chris Rees articulated: On Jun 2, 2012 5:27 PM, Jerry je...@seibercom.net wrote: On Sat, 2 Jun 2012 11:07:28 -0400 b. f. articulated: Realy no other possibility?! You need to rebuild all the ports that install binaries that link against libpngNN.so.NN. That is actually a subset of the ports that depend on graphics/png -- unfortunately it takes some effort to identify precisely what does need rebuilding. There is the pkg_libchk script (which is part of sysutils/bsdadminscripts) that can help. ... Use pkg_libchk to prioritise the ports that really need to be rebuilt. Lawrence Stewart's convenient script can be used with portmaster to perform this kind of update: https://lauren.room52.net/hg/scripts/raw-file/tip/libdepend/libdepend.sh I am receiving a: This Connection is Untrusted warning from Firefox when I attempt to connect to that URL. It is probably harmless; however, it certainly doesn't instill confidence is someone viewing the site for the first time. It just means he hasn't bought a certificate- no less trustworthy than vanilla (non-SSL) http. IMHO, if you are going to use https then you should have a proper SSL certificate. A self-signed one means virtually nothing. If the web site operator is not going to purchase an authentic certificate they why use SSL at all? Just my 2¢ on the matter. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ Graduate students and most professors are no smarter than undergrads. They're just older. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Please rebuild all ports that depend on PNG
On Sat, Jun 2, 2012 at 6:07 PM, Jerry je...@seibercom.net wrote: On Sat, 2 Jun 2012 17:34:59 +0100 Chris Rees articulated: On Jun 2, 2012 5:27 PM, Jerry je...@seibercom.net wrote: On Sat, 2 Jun 2012 11:07:28 -0400 b. f. articulated: Realy no other possibility?! You need to rebuild all the ports that install binaries that link against libpngNN.so.NN. That is actually a subset of the ports that depend on graphics/png -- unfortunately it takes some effort to identify precisely what does need rebuilding. There is the pkg_libchk script (which is part of sysutils/bsdadminscripts) that can help. ... Use pkg_libchk to prioritise the ports that really need to be rebuilt. Lawrence Stewart's convenient script can be used with portmaster to perform this kind of update: https://lauren.room52.net/hg/scripts/raw-file/tip/libdepend/libdepend.sh I am receiving a: This Connection is Untrusted warning from Firefox when I attempt to connect to that URL. It is probably harmless; however, it certainly doesn't instill confidence is someone viewing the site for the first time. It just means he hasn't bought a certificate- no less trustworthy than vanilla (non-SSL) http. IMHO, if you are going to use https then you should have a proper SSL certificate. A self-signed one means virtually nothing. If the web site operator is not going to purchase an authentic certificate they why use SSL at all? Just my 2¢ on the matter. No, it means that the transfer is encrypted. There is no guarantee that the site you are downloading from is the site you thought you were, but many people like to do https as a matter of principle. For this, self-signed certs are fine. And, if you think think a valid cert really guarantees anything other than encryption, you have not been paying attention to the news. There are lots of bogus, but properly signed certs out there. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Please rebuild all ports that depend on PNG
On Sat, Jun 02, 2012 at 02:07:03PM -0400, Jerry wrote: On Sat, 2 Jun 2012 17:34:59 +0100 Chris Rees articulated: It just means he hasn't bought a certificate- no less trustworthy than vanilla (non-SSL) http. IMHO, if you are going to use https then you should have a proper SSL certificate. A self-signed one means virtually nothing. If the web site operator is not going to purchase an authentic certificate they why use SSL at all? Just my 2¢ on the matter. 1. SSL means encrypted, regardless of who signs the certificate. 2. Using a known CA for certificate signing means a third party with enough clout to get added to a list of known CAs vouches for the certificate (or that someone else has somehow compromised that third party's cert signing resources). 3. Many trusted widely-known CAs have questionable policies with regard to certificate signing, and often use very weak ciphers for cert signing. On several occasions, government agencies and malicious security crackers have been found using bogus certs that verify as signed by legitimate CAs. 4. Regardless of who signs a cert, you still have to trust the site operators to some extent, because the encryption certainly doesn't stop *them* from getting the information you're sending, so in principle a self-signed cert is not in any way an indication of any lesser trustworthiness. 5. As long as you can get trustworthy confirmation of the provenance of a given cert's signature, you can verify the cert as authentic for the site in question, subject to the limitations of the technology used. The not-quite-obvious (to many, at least) consequence of the above is that the entire PKI system used by CAs for SSL is what amounts to a vacant lot scam. This is where a vacant parking lot -- owned by someone who is not making (much) use of it on a given occasion -- is claimed by someone wearing something like a valet uniform, who takes money in exchange for parking someone's car in the lot but actually has no relationship with the lot owner at all. The result is that people parking in the lot are being charged money for the promise of something (official, property-owner permission to park there, plus responsible care for the vehicles in question) that to some extent the person charging the money is not in a position to offer. The analogous condition in this case is that the well-known CAs are promising security and privacy that can be gotten by other, cheaper means, but to some extent do not even provide as high quality a guarantee as they would like you to think. Alternate verification infrastructures such as Monkeysphere and (my favorite, in terms of design principles) Perspectives provide roughly equivalent security value, and if they reach a threshhold of user density would exceed the security value of CA-signed certificates as a basis for verification. In addition to this, simply posting cert signature data publicly for out-of-band comparison could greatly enhance the verifiability of SSL site certificates, as with an OpenPGP public key. In fact, many of the weaknesses of SSL systems as currently designed could be obviated by having used OpenPGP as the basis of the system rather than creating this whole PKI system for the sole purpose of making corporate CAs seem necessary as imaginary authorities who claim to be able to provide special security guarantees. So . . . your opinion may be that a self-signed sertificate means virtually nothing, but security in the real world does not operate on unfounded opinions. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
