On Sun, Oct 14, 2012 at 11:38 PM, Maxim Kammerer wrote:
> there is currently no other way to
> enable physical DMA in Firewire than via firewire_sbp2 or via
> unfiltered physical DMA (enabled by CONFIG_FIREWIRE_OHCI_REMOTE_DMA).
Ah, there is also CONFIG_PROVIDE_OHCI1394_DMA_INIT +
ohci1394_dma=ea
On Sun, Oct 14, 2012 at 9:57 PM, Steve Weis wrote:
> There are two alternative driver stacks (e.g. ieee1394 and firewire-core)
> and the docs talk about them both interchangeably. It's a bit confusing. The
> CONFIG_FIREWIRE_OHCI_REMOTE_DMA kernel hacking option may only be relevant
> to the legacy
Hi,
as apparently I had committed myself to do so, I've just published the
release schedule we decided upon at last Tails summit:
https://tails.boum.org/contribute/release_schedule/
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR finge
Hi,
adrelanos wrote (27 Sep 2012 15:14:14 GMT) :
> I think it would be good if tails_htp security would be
> further improved.
I agree.
> Why not start pinning certificates?
Probably because nobody designed and implemented a working solution
yet. Looks like you started to. I'm glad you did, and
Hi,
adrelanos wrote (07 Oct 2012 17:43:53 GMT) :
> I wrote two scripts, perhaps they can be useful for Tails as well?
Thanks for the suggestion :)
I've been thinking a bit about this startup UX / waiting UI, and I'm
not sure we need/want that an invasive UI.
The general case is "all right, noth
intrigeri wrote (03 Oct 2012 18:39:31 GMT) :
> The release process doc and translation doc likely needs updating.
> IIRC the latter has a ticket already.
* release process doc: done
* translation doc: being worked on (see tails-l10n ML)
___
tails-dev ma
Hi,
Ague Mill wrote (01 Oct 2012 09:27:09 GMT) :
> I think the overhead of not using '--head' and doing a full GET
> would be marginal. It would make it at least a little bit harder to
> distinguish from other requests.
Fully agreed: this would make Tails' htpdate harder to distinguish
from the T
hi,
a...@boum.org wrote (04 Oct 2012 19:21:57 GMT) :
> Well no answer so far... but I took some time to play on this, and
> have some mockups to propose. Please test!
> I'd like to hear about:
> - your overall impression?
I like it.
> - should keyboard selectable independently from lo
Hi Maxim. I did not completely power off the system when I tried the test.
I did a warm reset and booted to a USB drive.
I'm not sure about the inconsistency with the debugging-via-ohci1394 docs.
There are two alternative driver stacks (e.g. ieee1394 and firewire-core)
and the docs talk about them
It used to be a pain in the behind. I would use Unetbootin or some
other tool to put an image on a USB thingie. Than boot that. Than use
that image to clone it on a second USB stick. Than boot into the new
one to test it and maybe create persistent media. Today I started the
ISO with a VirtualBox i
On Sat, Oct 13, 2012 at 5:18 AM, Maxim Kammerer wrote:
> On Sat, Oct 13, 2012 at 5:04 AM, Steve Weis wrote:
>> I think the kernel is working as expected. Debian and Ubuntu are both also
>> vulnerable by default, since FireWire modules are loaded automatically.
>
> From Documentation/debugging-via
Hi,
Jacob Appelbaum wrote (13 Oct 2012 11:02:17 GMT) :
> As this is a modular kernel - is there a reason not to simply add
> a "enable firewire" widget?
There are several I can see:
* It is a UX failure every time someone has to go out of their way to
have Tails work with their hardware.
* Eve
12 matches
Mail list logo
