Re: Lack of Flash support is no longer acceptable. Bounty established...
On Wed, Jun 25, 2008 at 09:21:53PM +0100, RW wrote: Btw there is a small nasty problem copy/paste from wine app to native apps does not work. Ideas how to workaround this? It's only the traditional X, select and middle-click, that doesn't work in my experience The windows-style explicit cut/copy/paste works for me with KDE in both directions. You could also use deskutils/autocutsel to help with this. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lack of Flash support is no longer acceptable. Bounty established...
On Tue, Jun 24, 2008 at 01:40:44PM -0600, Mark Carlson wrote: 0. Install wine ( emulators/wine ) 1. Download firefox for windows ( http://www.mozilla.com/en-US/firefox/all.html ) 2. Run: wine Firefox Setup 3.0.exe 3. Complete the installer 4. To run firefox you need to do something like: wine C:/Program Files/Mozilla Firefox/firefox.exe (I forget the exact path / command name) 5. Navigate to the adobe flash download page ( use goole or something ) and download the flash installer for windows. 6. When the download is complete, run it ( should be able to do this from the download manager in firefox ) 7. Complete the flash installer ( this will require you to close firefox, so do that ) 8. Start firefox again (see the wine firefox.exe command from above) 9. Create a script to start firefox under wine since the command is so ugly. This works surprisingly well. One note - you may want to undefine LC_CTYPE if you have it set to a non-standard value, as FF seems to crash otherwise. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lack of Flash support is no longer acceptable. Bounty established...
On Thu, Jun 19, 2008 at 02:37:48PM -0700, John Kozubik wrote: FreeBSD is not useful as a desktop environment without the ability to support Flash in a stable, well-performing fashion. Nonsense. This presumes anything useful has ever been written in flash. Free flash alternatives and flash movie players, etc., are, unfortunately, not a solution. While they certainly don't support everything perfectly, swfdec works fairly well for a large number of sites - notably YouTube and similar FLV wrappers, which is what most people ultimately use Flash for. Even if someone got Flash 9 working, we'll just be playing catch-up when Flash 10 is released and everything starts requiring it. While I honestly wish you the best of luck, I do think that developer effort is much better spent improving free implementations of Flash, as the spec is fairly open. If there are some particular things that don't work well for you with swfdec/gnash, why not offer a bounty to have those fixed? This would be more helpful to more people, like those not running FreeBSD, and those of us who don't use Linux binary compat - of which I suspect there are more than you assume. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Security Flaw in Popular Disk Encryption Technologies
On Sat, Feb 23, 2008 at 02:08:31PM +1300, Atom Smasher wrote: article below. does anyone know how this affects eli/geli? There's fairly little any disk crypto system can do to thoroughly defend against this. The best workaround currently is to turn off your machine when not in use. This has always been a good idea, since even without this attack, a running or sleeping machine can simply be retained until the appearance of a 0-day in the kernel or other running services. Granted, that often takes a while for FreeBSD. ;) Also, keeping your *really* sensitive data in a separate encrypted store which isn't always mounted is probably a good idea. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: macbook atheros driver in 7-beta2
On Tue, Nov 13, 2007 at 08:51:05AM -0800, brad clawsie wrote: i am looking for advice on the best alternative for wireless support, the provided ath driver does not provide support. sam leffler has a patch here http://people.freebsd.org/~sam/ath_hal-20070428.tgz but i am not sure if this is newer or older than the support in 7-beta2 It's newer, but has some known bugs. It's worth giving a try for the moment. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: packages, libfetch, and SSL
On Mon, Oct 22, 2007 at 10:07:33AM +0800, Adrian Chadd wrote: You can't (easily) cache data over SSL. Well, you can't use a HTTP proxy that doesn't break the SSL conversation and cache the updates. As someone who occasionally makes sure that distribution updates through a Squid proxy actually caches said updates, I'd really prefer you didn't stick package contents behind SSL. Fair enough. Now, we could take another approach of PGP-signing packages instead, but all the efforts I've seen to integrate PGP with the package management system in the past haven't gone anywhere. The changes above seem to be a bit more trivial than inventing a package-signing infrastructure and putting gpg or a BSD-licensed clone into base. Perhaps using SSL to sign packages and having a baked-in key would work as well. Considering its a solved problem (mostly!) in other distributions, and their updates are very cachable, why not do this? Sounds fine to me - I'll take a closer look at this. I'd still like to see the root CA certs merged into base so libfetch can be fixed. Does anyone object to just using the ones currently provided by the ca_root_nss port? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
packages, libfetch, and SSL
Hello, I've been doing some thinking about the security of the packages and ports system, and have noticed that there is something of a weak link when it comes to fetch/libfetch in general, and the way we do pkg_adds in particular. While updates to the ports tree happen in a pretty secure manner over portsnap, and distfiles are verified during the build process, packages added over pkg_add -r happen over plain FTP or HTTP without any verification, allowing packages to be swapped or corrupted by a network attacker. The lowest-impact way to fix this, I think, is to use SSL for pkg_adds. There are a couple of things that would need to change to make this happen. * Package distribution sites should use SSL over HTTP. Yes, this costs money. We can either find a way to use a free solution or get people to chip in - I'd gladly put some money up for this. * libfetch needs patched to verify SSL certificate CNs and to use SSL_CTX_set_verify on SSL contexts. It should really be considered a vulnerability that this currently doesn't happen, since SSL is meaningless without this. This is easy enough to fix (about 10 lines in libfetch/common.c), but is currently not feasible because: * CA certificates are not in the base system. CA certs are currently available in the security/ca_root_nss port. Is this suitable for importing to base? If not, why not? Now, we could take another approach of PGP-signing packages instead, but all the efforts I've seen to integrate PGP with the package management system in the past haven't gone anywhere. The changes above seem to be a bit more trivial than inventing a package-signing infrastructure and putting gpg or a BSD-licensed clone into base. Perhaps using SSL to sign packages and having a baked-in key would work as well. If we don't want to do any of this, I at least think that the current SSL support in libfetch should be removed entirely, or be accompanied by a very noisy error. Any thoughts? Cheers, David ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
