Areca Backup [LSARC/2008/681 Self Review]

[David Zhang]

Darren J Moffat 写道:
> Mark A. Carlson wrote:
>> Darren,
>>
>> This case is to provide familiarity to Linux users coming to OpenSolaris
>> and wanting to have the utilities here that they have in Linux. Once 
>> they
>> are comfortable and discover some of the superior tools that OpenSolaris
>> has that might be more appropriate, they will convert to those.
>
> Or the will continue to use tools with weak crypto that doesn't 
> actually backup their data 
There might be too concepts, one is backup correctly, two is to have 
crypto correctly.
The tool does it well.
> and whey will have a bad experience of that tool on OpenSolaris and 
> blame OpenSolaris not the tool.
>
If I were a software administrator, I would not think in that way. I 
will shot email to ask the author of this tool to enhance it. I need 
Solaris, I would also like to search more useful tools. But if I can not 
find, I will use the existing tools which I am pretty familiar with.

>> But if they need to learn all new tools when they first get here, they
>> will not stay.
>>
>> Darren J Moffat wrote:
>>> Given the unsafe nature of the crypto in this project and the fact 
>>> that it does not support ZFS ACLs or attributes I see no point in 
>>> integrating this into OpenSolaris/Solaris. 
>> See above. It's not a competition for only the best tool to be chosen 
>> for OpenSolaris, but more
>> a matter of many tools, some good, some much better.
>>> It would in my opinion be more harmful to have it than not have it. 
>>> It also provides a false sense of security due to the weak way that 
>>> the passphrases are turned into encryption keys (ie there is no 
>>> salting so no protection against brute force key attack).
>>>
>>> For personal backups it would be safer to use tar and if encryption 
>>> is needed then the encrypt(1) and mac(1) commands can be used for to 
>>> provide safer (than what this case provides) encrypted versions of 
>>> the tar files using a documented and committed format. Instead of 
>>> this project maybe we should build a simple personal backup tool 
>>> around the clis we already have in OpenSolaris.
>> There are better tools, but that is not a reason to reject 
>> familiarity cases,.
>
> It is for me, this is *my* opinion and I don't think this case should 
> be integrated for the reasons I've stated.
>
> The project team wanting to integrate this case can work upstream to 
> get the issues fixed. The data loss because it can't backup ACLs, and 
> other ZFS functionality I can not live with. This won't reflect badly 
> on this tool, in some peoples eyes it will reflect badly on ZFS or 
> badly on the integration we have done with this tool into OpenSolaris.
>
> If necessary I'll pull the derail lever and call for a vote, I'm happy 
> to write the opinion text to formally state my opinion but I'd rather 
> that the project team attempted to work with upstream developers to 
> resolve the issues first.
>
> These are security issues and security issues don't get to be brushed 
> under the carpet for familiarity cases.
>