Areca Backup [LSARC/2008/681 Self Review]

[Grant Zhang]

Sounds good to me. We probably need Darren's help on the security part.

Mark A. Carlson wrote:
> Grant,
>
> I think we need to document the limitations and direct the Areca
> user to the better tools that we have available that they may not
> be familiar with, along with the reasons why. If the limitations
> exist on other platforms/filesystems as well, they may be OK with
> those limitations if this is the best choice for that platform.
>
> This gives them the familiarity, yet nudges them towards the tools
> that will work better for them.
>
> -- mark
>
> Grant Zhang wrote:
>> Darren J Moffat wrote:
>>> Grant Zhang wrote:
>>>> I agree with Mark. The point of porting many FOSS packages into 
>>>> Open Solaris is to make people comfortable enough in using the very 
>>>> same tools in Open Solaris.
>>>>
>>>> Back to this case, Areca is a backup utility, not a crypto utility. 
>>>> Encryption is just one feature provided by Areca, although as you 
>>>> observed, not very strong encryption. It is possible to use Areca 
>>>> to back up the files totally unencrypted, which is not uncommon in 
>>>> personal backup space. For folks with strong security needs, 
>>>> encrypt(1) or mac(1) can still be used on the backups.
>>>
>>> Backup utilities need to backup *ALL* the data and *ALL* the 
>>> permissions.  If extended attribtues are not able to be included 
>>> then that is not *ALL* the data, if ACLs are not included then that 
>>> is not *ALL* the permissions.
>> Today's Areca does not support extended attributes and ACLs. Adding 
>> those is beyond the scope of porting though. It is up to the LSARC 
>> members to decide whether this limitation outweighs Areca's benefits.
>>>
>>>> Areca is an active project and a lot of people are using it on 
>>>> Windows and Linux. Please don't reject it so we have one less 
>>>> choice on OpenSolaris.
>>>
>>> Maybe on Windows and Linux it is sufficient but on OpenSolaris there 
>>> *WILL* be data loss and possibly security issues on restore due to a 
>>> lack of ACLs.
>>>
>>> There are still unanswered technical questions on the password/key 
>>> management as well.
>> The project documents do not seem to contain the answers so we need 
>> to dive into code. We will report back what we find.
>>>
>>> I am very close to derailing this case and voting deny so that an 
>>> opinion can be written however that is just my vote and the case 
>>> could still get approved if that happens.
>>>
>> OK, thanks for the info.