Re: Tarsnap died

2024-04-11 Thread jerry
 - Looks like I needed to run tarsnap-keygen again.  Also do "tarnsnap 
--fsck" to fix

the cache.
   Now it seems to be running normally.

   - JerryK



On 2024-04-11 08:47, jerry wrote:
OK, I have fixed all my email issues.  I now have operative SPF, DKIM, 
& DMARC.

And the big ISPs seem to be happy with it.  I am getting regular DMARC
reports from
yahoo and gmail & all is well.

I started up a new Tarsnap account.  My existing tarsnap installation
seems unable
to talk to it though.  Do I need to reinstall Tarsnap, create a new key 
etc?


  - Jerryk



On 2024-03-08 08:50, Norman Gray wrote:

Greetings

[trimming the CCs...]

This thread popped back into my head today, when I received a regular
reminder from another service I use, that it was about to renew.  The
alignment of emails prompts me to offer the observations below as
points of information, rather than necessarily advocating for anything
in particular

Short version: payment processing companies exist, and seem to do a
respectable job, in various senses.

I'm another person who thinks tarsnap's payment model is cute (and
long may it continue), but who would be more comfortable with a more
conventional one, as an option.

An email just appeared in my inbox saying

Your subscription will renew soon This is a friendly reminder that 
your XXX subscription for XXX will automatically renew on March 15, 
2024. Your payment method on file will be charged at that time. If 
your billing information has changed, you can update your payment 
details (https://XXX) now. Or if you would like to cancel, please 
visit our

website. Questions? Contact us at XXX@XXX.

Powered bystripe logo  (https://stripe.com)  |   Learn more about 
Stripe Billing (https://stripe.com/billing)


That ticks a lot of boxes for me.  It reminds me that Subscription X
is ongoing, it reassures me that I've got nothing to do, and it's
clear what to do if I decide to discontinue the service.  Good work,
Subscription X -- keep it up!

If I click on the 'learn more about Stripe Billing' link, I can find
more about compliance stuff, which includes documentation addressed to
the service owner [1] saying 'Checkout and Stripe.js and Elements host
all card data collection inputs within an iframe served from Stripe’s
domain (not yours) so your customers’ card information never touches
your servers.'  And lots more, more than I have the patience to read.
That is, the nice people at Subscription X (probably) _don't_ have my
card details stored locally.  However I'm fairly confident that
Subscription X (which includes being somewhat privacy-focused amongst
its declared goals) really _has_ read all that documentation.

Personally, I find this _more_ reassuring than if Subscription X were
managing this stuff themselves.  And more reassuring than if they were
doing something Imaginative and Creative about billing.
'Imaginative', 'creative' and 'billing' are not words that go well
together in a sentence!

Of course, there's the matter of trust.

I don't trust Stripe to be nice people, in a 'would I lend them money'
sense.  I've no reason to believe they're not sunlight-and-kittens
(though... financial organisation... the priors aren't good), but that
trust isn't part of the transaction.  I do, however, trust them to
look after my card details reasonably well, because doing so is the
entire point of their business, and if they were to visibly screw up
here, it could be devastating for them.  That's a very concrete
incentive.

There's more I could say here, but: for billing I want boring.

Best wishes,

Norman


[1] https://docs.stripe.com/security/guide#validating-pci-compliance


Re: Tarsnap died

2024-04-11 Thread jerry
OK, I have fixed all my email issues.  I now have operative SPF, DKIM, & 
DMARC.
And the big ISPs seem to be happy with it.  I am getting regular DMARC 
reports from

yahoo and gmail & all is well.

I started up a new Tarsnap account.  My existing tarsnap installation 
seems unable
to talk to it though.  Do I need to reinstall Tarsnap, create a new key 
etc?


  - Jerryk



On 2024-03-08 08:50, Norman Gray wrote:

Greetings

[trimming the CCs...]

This thread popped back into my head today, when I received a regular
reminder from another service I use, that it was about to renew.  The
alignment of emails prompts me to offer the observations below as
points of information, rather than necessarily advocating for anything
in particular

Short version: payment processing companies exist, and seem to do a
respectable job, in various senses.

I'm another person who thinks tarsnap's payment model is cute (and
long may it continue), but who would be more comfortable with a more
conventional one, as an option.

An email just appeared in my inbox saying

Your subscription will renew soon This is a friendly reminder that 
your XXX subscription for XXX will automatically renew on March 15, 
2024. Your payment method on file will be charged at that time. If 
your billing information has changed, you can update your payment 
details (https://XXX) now. Or if you would like to cancel, please 
visit our

website. Questions? Contact us at XXX@XXX.

Powered bystripe logo  (https://stripe.com)  |   Learn more about 
Stripe Billing (https://stripe.com/billing)


That ticks a lot of boxes for me.  It reminds me that Subscription X
is ongoing, it reassures me that I've got nothing to do, and it's
clear what to do if I decide to discontinue the service.  Good work,
Subscription X -- keep it up!

If I click on the 'learn more about Stripe Billing' link, I can find
more about compliance stuff, which includes documentation addressed to
the service owner [1] saying 'Checkout and Stripe.js and Elements host
all card data collection inputs within an iframe served from Stripe’s
domain (not yours) so your customers’ card information never touches
your servers.'  And lots more, more than I have the patience to read.
That is, the nice people at Subscription X (probably) _don't_ have my
card details stored locally.  However I'm fairly confident that
Subscription X (which includes being somewhat privacy-focused amongst
its declared goals) really _has_ read all that documentation.

Personally, I find this _more_ reassuring than if Subscription X were
managing this stuff themselves.  And more reassuring than if they were
doing something Imaginative and Creative about billing.
'Imaginative', 'creative' and 'billing' are not words that go well
together in a sentence!

Of course, there's the matter of trust.

I don't trust Stripe to be nice people, in a 'would I lend them money'
sense.  I've no reason to believe they're not sunlight-and-kittens
(though... financial organisation... the priors aren't good), but that
trust isn't part of the transaction.  I do, however, trust them to
look after my card details reasonably well, because doing so is the
entire point of their business, and if they were to visibly screw up
here, it could be devastating for them.  That's a very concrete
incentive.

There's more I could say here, but: for billing I want boring.

Best wishes,

Norman


[1] https://docs.stripe.com/security/guide#validating-pci-compliance


Re: Tarsnap died

2024-03-08 Thread Norman Gray


Greetings

[trimming the CCs...]

This thread popped back into my head today, when I received a regular reminder 
from another service I use, that it was about to renew.  The alignment of 
emails prompts me to offer the observations below as points of information, 
rather than necessarily advocating for anything in particular

Short version: payment processing companies exist, and seem to do a respectable 
job, in various senses.

I'm another person who thinks tarsnap's payment model is cute (and long may it 
continue), but who would be more comfortable with a more conventional one, as 
an option.

An email just appeared in my inbox saying

> Your subscription will renew soon This is a friendly reminder that your XXX 
> subscription for XXX will automatically renew on March 15, 2024. Your payment 
> method on file will be charged at that time. If your billing information has 
> changed, you can update your payment details (https://XXX) now. Or if you 
> would like to cancel, please visit our
> website. Questions? Contact us at XXX@XXX.
>
> Powered bystripe logo  (https://stripe.com)  |   Learn more about Stripe 
> Billing (https://stripe.com/billing)

That ticks a lot of boxes for me.  It reminds me that Subscription X is 
ongoing, it reassures me that I've got nothing to do, and it's clear what to do 
if I decide to discontinue the service.  Good work, Subscription X -- keep it 
up!

If I click on the 'learn more about Stripe Billing' link, I can find more about 
compliance stuff, which includes documentation addressed to the service owner 
[1] saying 'Checkout and Stripe.js and Elements host all card data collection 
inputs within an iframe served from Stripe’s domain (not yours) so your 
customers’ card information never touches your servers.'  And lots more, more 
than I have the patience to read.  That is, the nice people at Subscription X 
(probably) _don't_ have my card details stored locally.  However I'm fairly 
confident that Subscription X (which includes being somewhat privacy-focused 
amongst its declared goals) really _has_ read all that documentation.

Personally, I find this _more_ reassuring than if Subscription X were managing 
this stuff themselves.  And more reassuring than if they were doing something 
Imaginative and Creative about billing.  'Imaginative', 'creative' and 
'billing' are not words that go well together in a sentence!

Of course, there's the matter of trust.

I don't trust Stripe to be nice people, in a 'would I lend them money' sense.  
I've no reason to believe they're not sunlight-and-kittens (though... financial 
organisation... the priors aren't good), but that trust isn't part of the 
transaction.  I do, however, trust them to look after my card details 
reasonably well, because doing so is the entire point of their business, and if 
they were to visibly screw up here, it could be devastating for them.  That's a 
very concrete incentive.

There's more I could say here, but: for billing I want boring.

Best wishes,

Norman


[1] https://docs.stripe.com/security/guide#validating-pci-compliance


-- 
Norman Gray  :  https://nxg.me.uk


Re: Tarsnap died

2024-03-07 Thread tarsnap
On Wed, Mar 6, 2024, at 9:58 AM, Scott Wheeler wrote:
> 
>> On Mar 6, 2024, at 07:10, tars...@sehe.nl wrote:
>> 
>> 
>> I will remind you that calling a missing feature "insane" is not usually 
>> part of "reasonable customer feedback", so I might have been a little more 
>> curt in my response just to balance things out. There you go,
> 
> I called it inane, not insane.  If you want to quote me, my word was 
> “redonkulous”.  ;-)
I totally misread that! Sorry. To be completely frank, I'm not sure "inane" is 
much friendlier, but it sure wasn't my intention to accuse you of using an even 
unfriendlier word.



Re: Tarsnap died

2024-03-07 Thread Aaron C. de Bruyn via tarsnap-users
Seems like there's a simple solution to this:

I have a calendar item that pops up every month and reminds me to check my
balance.

When it gets low, I recharge it with enough to last me for anywhere from
3-12 months at a whack because sometimes I'm busy when the reminder pops up.

It's worked pretty well for a long time now...and when it didn't, I have a
reasonably configured mail system and I get several messages from Colin
reminding me that I forgot for several months in a row.  Failing all that,
I'm pretty sure tarsnap will start failing backups, and if I'm a competent
geek, I'm monitoring cron output for failures...especially when it deals
with the ability to recover data in a disaster.

If there was a way to store a card and recharge based on settings (maybe
"When my account balance drops below $x, automatically charge $y to the
card") I would probably use it...but I couldn't care less if it got
implemented or not.

-A

On Thu, Mar 7, 2024 at 9:09 AM Michael Sierchio  wrote:

>
> On Thu, Mar 7, 2024 at 11:55 AM Jeffrey Goldberg 
> wrote:
>
>
>> ... I am extremely sympathetic to focusing on the core service instead of
>> having to build, maintain, and protect systems that store secrets needed
>> for payment.
>>
>
> There is no need to store payment information.  A token corresponding to a
> user is all that's required for payment systems (of which there is a
> multitude).  Even enrollment doesn't require a merchant to capture or even
> see credit card information.
>
> This is what most merchants do – focus on their core business and
> outsource payment processing.
>
> One could argue that autopay is less disruptive and intrusive than having
> an account deleted.
>
> – M
>


Re: Tarsnap died

2024-03-07 Thread Michael Sierchio
On Thu, Mar 7, 2024 at 11:55 AM Jeffrey Goldberg 
wrote:


> ... I am extremely sympathetic to focusing on the core service instead of
> having to build, maintain, and protect systems that store secrets needed
> for payment.
>

There is no need to store payment information.  A token corresponding to a
user is all that's required for payment systems (of which there is a
multitude).  Even enrollment doesn't require a merchant to capture or even
see credit card information.

This is what most merchants do – focus on their core business and outsource
payment processing.

One could argue that autopay is less disruptive and intrusive than having
an account deleted.

– M


Re: Tarsnap died

2024-03-07 Thread Jeffrey Goldberg

On Mar 4, 2024, at 14:28, Scott Wheeler  wrote:

> it’s kind of redonkulous that there’s not an auto-recharge option.

There are some who consider automatic renewal or recharge to be evil. I am not 
going to argue either way for any particular service, but I want to point out 
that this is one of those trade-offs that need to be made, often with no 
“right” answer. Other design decisions affect trade-offs between data 
confidentiality and data availability are similar. There is no single perfect 
balance that will work for all users.

There are only “least bad” answers for a particular system. There is also a 
whole lot of overhead to holding on to payment information. Tarsnap systems 
seem to be set up so that there is little value to an attacker to try to 
compromise the servers. That makes defending the servers against attack much 
easier. In another context about a different service, I called this the 
“Principle of Cowardice”: Don’t hold on to something an attacker might want.

Personally, I feel that Tarsnap has made the better choices. But I also would 
advise that these sorts of things are occasionally reviewed as the user-base 
changes. Still, I am extremely sympathetic to focusing on the core service 
instead of having to build, maintain, and protect systems that store secrets 
needed for payment.

Cheers,

-j





smime.p7s
Description: S/MIME cryptographic signature


Re: Tarsnap died

2024-03-06 Thread Scott Wheeler

> On Mar 6, 2024, at 07:10, tars...@sehe.nl wrote:
> 
> 
> I will remind you that calling a missing feature "insane" is not usually part 
> of "reasonable customer feedback", so I might have been a little more curt in 
> my response just to balance things out. There you go,


I called it inane, not insane.  If you want to quote me, my word was 
“redonkulous”.  ;-)

-Scott

Re: Tarsnap died

2024-03-05 Thread tarsnap
On Wed, Mar 6, 2024, at 4:03 AM, Scott Wheeler wrote:
> 
>> To me the audience for Tarsnap is the privacy minded part of the public. 
>> Having payment details on file sort of contradicts the mission. That's (I'm 
>> guessing) why tarsnap is 100% pre-paid. 
>> 
>> You're free not to use it, or create your own process for regularly topping 
>> up the balance. Heck, you could even put $50 there and probably have a 
>> lifetime of storage (it's been a while since I used tarsnap, but back when 
>> it was /dirt cheap/ and I imagine storage costs have not increased 
>> significantly over time.
> 
> You’re free to think that, but my company has spent thousands (perhaps over 
> $10k at this point?) on Tarsnap, so I don’t have a bad feeling saying, “I 
> love the service, but this part I find kind of dumb” is out of the range of 
> reasonable customer feedback.  It’s reasonable to  keep in mind that there 
> are different kinds of customers on this list, and that for some of us $50 is 
> not what we’re talking about.  I suspect what pays Collin’s rent are the 
> customers that pay that much every month.
> 
> -Scott

I don't suspect there is much of a profit margin, but let's not argue things we 
hardly can know¹. I agree this is valid feedback. I also took it seriously by 
providing what I think is reasonable explanation.

I will remind you that calling a missing feature "insane" is not usually part 
of "reasonable customer feedback", so I might have been a little more curt in 
my response just to balance things out. There you go,

Peace

¹ I half-remember Colin writing about this many years ago but (a) I'm not 
searching for it (b) things may have changed over time

Re: Tarsnap died

2024-03-05 Thread Scott Wheeler

> To me the audience for Tarsnap is the privacy minded part of the public. 
> Having payment details on file sort of contradicts the mission. That's (I'm 
> guessing) why tarsnap is 100% pre-paid. 
> 
> You're free not to use it, or create your own process for regularly topping 
> up the balance. Heck, you could even put $50 there and probably have a 
> lifetime of storage (it's been a while since I used tarsnap, but back when it 
> was /dirt cheap/ and I imagine storage costs have not increased significantly 
> over time.

You’re free to think that, but my company has spent thousands (perhaps over 
$10k at this point?) on Tarsnap, so I don’t have a bad feeling saying, “I love 
the service, but this part I find kind of dumb” is out of the range of 
reasonable customer feedback.  It’s reasonable to  keep in mind that there are 
different kinds of customers on this list, and that for some of us $50 is not 
what we’re talking about.  I suspect what pays Collin’s rent are the customers 
that pay that much every month.

-Scott

Re: Tarsnap died

2024-03-05 Thread tarsnap
On Mon, Mar 4, 2024, at 9:28 PM, Scott Wheeler wrote:
> Tarsnap is the only important service we use with a billing system this inane 
> … and people have been complaining about it for at least a decade.

To me the audience for Tarsnap is the privacy minded part of the public. Having 
payment details on file sort of contradicts the mission. That's (I'm guessing) 
why tarsnap is 100% pre-paid.

You're free not to use it, or create your own process for regularly topping up 
the balance. Heck, you could even put $50 there and probably have a lifetime of 
storage (it's been a while since I used tarsnap, but back when it was /dirt 
cheap/ and I imagine storage costs have not increased significantly over time.

Just my $0.02

Re: Tarsnap died

2024-03-04 Thread Scott Wheeler


> On Mar 4, 2024, at 21:03, jerry  wrote:
> 
> That means that when I get my email house in order,
> I should be able to comfortably use Tarsnap again.

Except that it’s kind of redonkulous that there’s not an auto-recharge option.  
That obviously doesn’t completely side-step the issue since credit cards expire 
too, but two levels of redundancy for such a critical infrastructure piece 
would be already a giant improvement.  Tarsnap is the only important service we 
use with a billing system this inane … and people have been complaining about 
it for at least a decade.

-Scott

Re: Tarsnap died

2024-03-04 Thread jerry

OK,

   Yet another email problem.  I've been fighting with that for a while. 
 I've been
running my own email server since the 90's.  That's not as easy as it 
used to be.  New
security protocols are becoming necessary.  The original symptom was 
that outgoing emails would
be dumped on the floor by the big ISP's, especially Google.  So I tried 
to install them.


The first was SPF.  That one's easy.  You stick in a DNS record that 
says "don't accept
any emails claiming to come from my domain except from IP address 
x.x.x.x".


Then DKIM - that's a lot harder.  A cryptographic hash is done of 
outgoing messages, and
you check it on the incoming, getting the public key from the domain's 
DNS.


I think that's my problem for incoming.  DKIM filtering is not working 
correctly.  Strangely
enough, I still mostly get all the email from everybody.  Apparently, 
except you.  This doesn't
mean that your DKIM is wrong;  it surely means that my installation is 
bad.


My server is Slackware-based.  A new Slackware just came out, and I'm 
installing that on another
machine.  On that machine, I'm moving from Sendmail to Postfix, which is 
supposed to be more modern,

less cruft, and easier to admin.

But there's a LOT of stuff to get working on that new server before 
cutting over.  And it's an inferior
machine.  Just a Dell desktop PC.  The plan is to get the new server 
running, then update the old server ( which is a

true server machine with ECC RAM ) and cut back over to that.

I'm glad to know that there were multiple terse emails.  That means that 
when I get my email house in order,

I should be able to comfortably use Tarsnap again.

Will I have to generate a new key for a new account?

Strangely enough, the mailing list is coming in fine.  In real time, not 
off the archive.


  - je...@tr2.com








On 2024-03-04 11:24, Colin Percival wrote:

On 3/4/24 11:13, jerry wrote:
This "one terse email then delete your data a week later" thing just 
didn't work this time.


My mail server is failing to connect to your mail server, but just in 
case
you can read this via the mailing list archives: You should have 
received
emails on 2023-10-19 ("balance < 7 days of storage"), 2023-10-26 
("balance
is negative"), 2023-11-15 ("account will be deleted soon") and 
2023-11-22
(a personal email because I was concerned that I hadn't heard back from 
you).


The account was deleted on 2024-01-09.


Re: Tarsnap died

2024-03-04 Thread Colin Percival

On 3/4/24 11:13, jerry wrote:
This "one terse email then delete your data a week later" thing just didn't 
work this time.


My mail server is failing to connect to your mail server, but just in case
you can read this via the mailing list archives: You should have received
emails on 2023-10-19 ("balance < 7 days of storage"), 2023-10-26 ("balance
is negative"), 2023-11-15 ("account will be deleted soon") and 2023-11-22
(a personal email because I was concerned that I hadn't heard back from you).

The account was deleted on 2024-01-09.

--
Colin Percival
FreeBSD Release Engineering Lead & EC2 platform maintainer
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid


Tarsnap died

2024-03-04 Thread jerry

Greetings tarsnap users.

Not Happy.  But it's my own fault

I've been using tarsnap for many years.  In general, I do NOT trust the 
"cloud", and do not use google/microsoft/etc to store any sensitive 
data.  The combination of encryption on my home server and deduplication 
is compelling.  I do not know of any big-commercial service that offers 
comparable.  Yup, truly paranoid :).


 I have a script that upchucks my business & personal data once a week.  
Was running about a dollar a day in backup costs because I'm too lazy to 
figure out what to back up or not back up on a regular basis.


Yesterday, I had reason to restore a file that I had stupidly deleted, 
and none of my on-site backups had it.  Nothing
super important, just the latest version of the source code for a ham 
radio gadget I had created.


So I said "tarsnap --list-archives".  The network timed out.  OK, I 
tried pinging the magic tarsnap IPv4 address - that did work.  Telnetted 
to the magic port# of the magic IP...that worked.


I could only guess that I had so many archives that things timed out 
while the tarsnap server was trying to list them.


Came down this morning to try to jigger the code to time out slower.  No 
luck.


Then I tried logging into my tarsnap account on the management web page. 
 "Unknown user"huh?


OK, I searched though my emails and sure enough there was one of those 
"your tarsnap balance will run out in 7 days" messages from back in 
November.


I get LOTS of emails.  I have had the same email address since 1991 ( 
UUCP back then ) and I am surely on every spam list known to man.  Right 
now, my inbox has over 6000 messages.  That's maybe six months of 
accumulation despite my best efforts to constantly file, respond, and 
delete them.  And running spamassassin to delete crud before it even 
makes it to my inbox.


If I miss an email for a day or two, it's PAGES back when I get back to 
the machine.


This "one terse email then delete your data a week later" thing just 
didn't work this time.


How to get around it?  I could write a procmail script to do something 
when anything comes in from tarsnap.com???
Do what?  Send a text message to my phone?  For me, those are even worse 
than emails.  I follow emails religiously,

text messages not so much.

In my business, I do have access to a web API that sends snail mail ( 
postalmethods.com ).  Have it send me a letter for each "7 days till 
death" email?  Might not get to me fast enough.


A procmail script that fires off a cron job that sends me an email an 
hour for the 7 days?


An asterisk script that calls me up on the phone and says "Whh 
whh whh tarsnap alert!  TARSNAP ALERT!" ?


I guess since November, my cron task has been cheerfully upchucking 
backups to that bit bucket in the sky.


I reasonably expect to be in business another 10 years.  I suppose I 
could guesstimate how much tarsnap I will
use over that period, and just send Colin that much $$.  But will HE be 
in business for 10 years?  What if he

gets run over by a bus?

 - je...@tr2.com