Il 04/05/2011 20:48, Pavel Sanda ha scritto:
No need for HTTPS.
so on the top of introducing network stuff into lyx, we will also incorporate
libraries of gnupg into our code :)
There's always the option of:
~~ system("wget ... && gpg ... && cp ... $HOME/.lyx/...");
without "bloating" furth
Am 04.05.2011 um 21:57 schrieb Pavel Sanda:
> venom00 wrote:
>> I have no idea of how heavy is gunpg, but I agree with that is probably too
>> much, HTTPS is more than enough. Network stuff are well managed by Qt, aren't
>> they?
>
> no, i rather meant that the whole download idea if not good way
venom00 wrote:
> I have no idea of how heavy is gunpg, but I agree with that is probably too
> much, HTTPS is more than enough. Network stuff are well managed by Qt, aren't
> they?
no, i rather meant that the whole download idea if not good way to follow ;)
pavel
> something like we do with packages.
Yes, but the Debian example was more notable to me :)
> > No need for HTTPS.
>
> so on the top of introducing network stuff into lyx, we will
> also incorporate
> libraries of gnupg into our code :)
I have no idea of how heavy is gunpg, but I agree with t
venom00 wrote:
> without the proper authentication process. However if you prefer we can sign
> the
> files with PGP, something like Debian does with packages.
something like we do with packages.
> No need for HTTPS.
so on the top of introducing network stuff into lyx, we will also incorporate
> venom00 wrote:
> > Well... But they didn't generate a fake certificate for lyx.org :P
>
> yet. P
To be honest I think that the last thing a malicious cracker would do, having
the possibility to create trusted certificates, is using them for lyx.org.
Private keys have not been compromised, they
venom00 wrote:
> Well... But they didn't generate a fake certificate for lyx.org :P
yet. p
> Yes. The page above sounds harmless. Read http://www.h-
> online.com/news/item/SSL-meltdown-forces-browser-developers-to-
> update-1213358.html if you want a better picture. Basically,
> revoking of SSL
> certificates is broken by design, so the stolen certificates
> need to be
> disabled by
venom00 wrote:
>> On Mon, May 2, 2011 at 7:49 PM, Georg Baum
>> wrote:
>> > An automatic download button is too dangerous IMHO. If you
>> offer that you
>> > need to keep track of security issues, e.g. the recent SSL
>> certificate
>> > desaster.
>> >
>> Of curiosity, which one? Wikipedia doesn't
> On Mon, May 2, 2011 at 7:49 PM, Georg Baum
> wrote:
> > An automatic download button is too dangerous IMHO. If you
> offer that you
> > need to keep track of security issues, e.g. the recent SSL
> certificate
> > desaster.
> >
> Of curiosity, which one? Wikipedia doesn't say much.
> Liviu
May
On Mon, May 2, 2011 at 7:49 PM, Georg Baum
wrote:
> An automatic download button is too dangerous IMHO. If you offer that you
> need to keep track of security issues, e.g. the recent SSL certificate
> desaster.
>
Of curiosity, which one? Wikipedia doesn't say much.
Liviu
Georg Baum wrote:
> An automatic download button is too dangerous IMHO. If you offer that you
> need to keep track of security issues, e.g. the recent SSL certificate
> desaster.
and effectively spoils any pgp protection we tried to introduce
for tabralls and binaries.
pavel
Richard Heck wrote:
> That's my general sense, too: It's a corner case, and File>Export isn't
> that difficult.
>
> For what it's worth, I don't really like the "save in the original
> format" idea either. It's nice that LyX can export to older formats,
> etc, but I'm not sure we really want to p
On Mon, May 2, 2011 at 1:53 PM, Richard Heck wrote:
>> Agreed. Could we make this easily available on the net and add the URL to
>> the error message like
>>
>> If this file is from a newer LyX version, try to download the
>> conversion script www.lyx.org/downloads/newest-stable/lyx2lyx.py a
On Sun, May 1, 2011 at 10:49 PM, Jean-Marc Lasgouttes
wrote:
> Le 30/04/11 15:38, Richard Heck a écrit :
>>>
>>> Would it be difficult to automate this? I was thinking that the best
>>> solution to the problem, from a LyX point of view, was to provide---in
>>> addition to the current message---a b
On 05/01/2011 06:59 PM, Guenter Milde wrote:
> On 2011-05-01, Richard Heck wrote:
>
> ... [Resons for not up-and-downgrading on a regular basis] ...
>
>> People who want to collaborate with users of earlier versions (or use
>> development versions for their own work, etc) should have the users of
>
On 2011-05-01, Richard Heck wrote:
... [Resons for not up-and-downgrading on a regular basis] ...
> People who want to collaborate with users of earlier versions (or use
> development versions for their own work, etc) should have the users of
> those earlier versions install their (newer) version
Richard Heck wrote:
> etc, but I'm not sure we really want to people to try to collaborate
> across major versions and then start reporting bugs when it doesn't work.
+1
pavel
On 05/01/2011 04:49 PM, Jean-Marc Lasgouttes wrote:
> Le 30/04/11 15:38, Richard Heck a écrit :
>>> Would it be difficult to automate this? I was thinking that the best
>>> solution to the problem, from a LyX point of view, was to provide---in
>>> addition to the current message---a button that wou
On Sun, May 1, 2011 at 11:41 PM, Liviu Andronic wrote:
> On Sun, May 1, 2011 at 10:54 PM, venom00 wrote:
>> This requires a "permanent" connection to the Internet while LyX is an
>> offline
>> application.
>>
> This might actually work: after receiving a problematic LyX file by
> e-mail make sur
On Sun, May 1, 2011 at 10:54 PM, venom00 wrote:
> This requires a "permanent" connection to the Internet while LyX is an offline
> application.
>
This might actually work: after receiving a problematic LyX file by
e-mail make sure that you have an internet connection for couple more
minutes. :) Th
> IMO the problem is more what happens when someone hits this
> button with
> LyX version 2.0 and current version is 4.1. Are we sure we
> have kept the
> same interface to lyx2lyx? Are we going to be bound by that forever?
Well, if we want to make big changes giving a new name to the file is
Le 30/04/11 15:38, Richard Heck a écrit :
Would it be difficult to automate this? I was thinking that the best
solution to the problem, from a LyX point of view, was to provide---in
addition to the current message---a button that would download most
recent lyx2lyx from SVN or trac and place it to
On 2011-04-29, stefano franchi wrote:
> On Fri, Apr 29, 2011 at 9:11 AM, Julien Rioux
> wrote:
>> On 29/04/2011 10:03 AM, Richard Heck wrote:
couldn't you give your colleagues file exported to 1.6 on your side?
> A possible solution would be to imitate what Openoffice does
...
> If a file i
On 29/04/2011 5:31 PM, Richard Heck wrote:
On 04/29/2011 10:11 AM, Julien Rioux wrote:
Can I raise a question again? Why not always backport changes to lyx2lyx
from trunk to branch? Of course branch releases will run slightly behind
trunk, but not so badly that it would be useless to do this. Th
On Sat, Apr 30, 2011 at 3:58 PM, venom00 wrote:
>> Yes, though it seems kind of dangerous to download python scripts from
>> the web and then offer to run them.
>
> We could add HTTPS to lyx.org and use a free certificate from StartSSL [1],
> which is a trusted CA.
>
Yes, I also thought of this. W
> Yes, though it seems kind of dangerous to download python scripts from
> the web and then offer to run them.
We could add HTTPS to lyx.org and use a free certificate from StartSSL [1],
which is a trusted CA.
venom00
[1] http://www.startssl.com/
On 04/30/2011 01:24 AM, Liviu Andronic wrote:
> On Fri, Apr 29, 2011 at 11:31 PM, Richard Heck wrote:
>> I thought the original question was precisely about interoperability between
>> the stable version and development versions. In that case, regularly porting
>> lyx2lyx does help. Then again, th
On Fri, Apr 29, 2011 at 11:31 PM, Richard Heck wrote:
> I thought the original question was precisely about interoperability between
> the stable version and development versions. In that case, regularly porting
> lyx2lyx does help. Then again, this is probably a special case, and anyone
> who run
On 04/29/2011 10:11 AM, Julien Rioux wrote:
Can I raise a question again? Why not always backport changes to lyx2lyx
from trunk to branch? Of course branch releases will run slightly behind
trunk, but not so badly that it would be useless to do this. Then, to
some extent, the problem goes away, e
Richard Heck wrote:
> It shouldn't. One loses data in the sense that insets can get converted to
> ERT, but you shouldn't lose data in any other sense.
there are features which are lost during the conversion back simply because
there is nothing comparable in previous versions. secondly if we do s
On Fri, Apr 29, 2011 at 9:11 AM, Julien Rioux
wrote:
> On 29/04/2011 10:03 AM, Richard Heck wrote:
>>> couldn't you give your colleagues file exported to 1.6 on your side?
A possible solution would be to imitate what Openoffice does (and
perhaps Microsoft word as well, I don't know) when dealing
On 29/04/2011 10:03 AM, Richard Heck wrote:
On 04/29/2011 09:53 AM, Pavel Sanda wrote:
Tommaso Cucinotta wrote:
What is wrong with such an approach ?
The data loss thingy: it's very dangerous and naive users (but even
developers!) could suffer.
As far as the user is notified, I can't see a re
On 04/29/2011 09:53 AM, Pavel Sanda wrote:
Tommaso Cucinotta wrote:
What is wrong with such an approach ?
The data loss thingy: it's very dangerous and naive users (but even
developers!) could suffer.
As far as the user is notified, I can't see a real problem here
unnoticed dataloss in your c
Tommaso Cucinotta wrote:
What is wrong with such an approach ?
>> The data loss thingy: it's very dangerous and naive users (but even
>> developers!) could suffer.
>
> As far as the user is notified, I can't see a real problem here
unnoticed dataloss in your conversion step seems to me quite
Oops! message sent too fast! Next part.
Le 29/04/2011 15:34, Jean-Marc Lasgouttes a écrit :
Le 29/04/2011 15:25, Tommaso Cucinotta a écrit :
I don't know whether lyx2lyx is designed to solely upgrade the file
format, or also to downgrade it, because in the former case it wouldn't
help.
Of cou
Le 29/04/2011 15:25, Tommaso Cucinotta a écrit :
Il 29/04/2011 05:02, Richard Heck ha scritto:
There's an even better solution: Copy current lyx2lyx from trunk. So
let me ask this question: Is there any real reason not to backport
lyx2lyx to branch as it changes?
Well, trunk is affected by tha
Il 29/04/2011 06:09, Liviu Andronic ha scritto:
On Fri, Apr 29, 2011 at 5:02 AM, Richard Heck wrote:
What is wrong with such an approach ?
The data loss thingy: it's very dangerous and naive users (but even
developers!) could suffer.
As far as the user is notified, I can't see a real problem
Il 29/04/2011 05:02, Richard Heck ha scritto:
There's an even better solution: Copy current lyx2lyx from trunk. So
let me ask this question: Is there any real reason not to backport
lyx2lyx to branch as it changes?
Well, trunk is affected by that problem as well: create the simplest LyX
docum
On Fri, Apr 29, 2011 at 5:02 AM, Richard Heck wrote:
>> What is wrong with such an approach ?
>
The data loss thingy: it's very dangerous and naive users (but even
developers!) could suffer.
>
> There's an even better solution: Copy current lyx2lyx from trunk. So let me
> ask this question: Is t
On 04/28/2011 10:30 PM, Tommaso Cucinotta wrote:
Hi all,
a problem that comes to me from time to time is the one to open with
an older version of LyX a file generated with a newer one (i.e.,
trying to open with 1.6 files generated with trunk).
I'm astonished by the:
1) inability of lyx to ev
41 matches
Mail list logo
