Disclaimer

The content of this blog is my personal opinion only. Although I am an employee - currently of Imagination Technologies's MIPS group, in the past of other companies such as Intellectual Ventures, Intel, AMD, Motorola, and Gould - I reveal this only so that the reader may account for any possible bias I may have towards my employer's products. The statements I make here in no way represent my employer's position, nor am I authorized to speak on behalf of my employer. In fact, this posting may not even represent my personal opinion, since occasionally I play devil's advocate.

See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.

Wednesday, November 30, 2016

Your most important passwords a probabl your weakest passwords

Have you ever noticed that your most important passwords are your weakest passwords?



Most of my passwords are random 20-24-32 Letter+Number*Symbol=Passwords. Stored in a password manager, because I can't remember them. Several hundred, different for each site. For that matter the account names and email are mostly different. Automatically entered into websites when I say okay. I am less happy when I have to cut and paste passwords, because clipboards can be a security hole. Anyway, not only do I not need to remember these passwords, but I don't have to type them in.



So, consider the passwords left over.



First, (1)  the password for the password manager itself. My most important password. Because I have to remember it, and type it on at least 2 different keyboards - phone, laptop - it probably has less entropy than most of the passwords in my password manager.



Worse: it is long enough and hard enough to type that I have more than once hit "show me my password", when repeated tries fail.  So any camera looking over my shoulder may have captured it from the screen.  Like a security camera in an airport.



Of course, even without "show me my password", a camera may see your typing.



Change it frequently, but then entry errors rise.



When I have trouble entering my password usually arises on my iPhone keyboard. Good passwords are easier to type on a full keyboard.  Not only are mobile phone keyboards, and in particular Apple's iPhone keyboards, cramped and likely to produce wrong key errors - but you also have to shift to get numbers and symbols. Sometimes multiple shifts.



Oh, and you probably should have audible keyclicks turned off. Have you noticed that Apple provides a different click for the shift key that changes between lowercase, uppercase, numbers, and symbols?  I am sure anyone with a microphone can record that and greatly reduce the password search space.  Even without different clicks, inter-key delay provides a lot of attack info.



Recently I have had to do a factory reset and reinstall from scratch on my Apple iPhone 3 times within the same month.  (I think/hope the iPhone flash storage has errors - or else the iOS apps are full of bugs that may become security holes.)



Doing this has driven home how many times you have to type in (2) the password for the device itself, and (3) Apple's iCloud password.



Now, device passwords, such as for your phone or tablet or laptop, of necessity need to be typed in a lot. One of the best things about fingerprints is that, ideally, you can use the fingerprint to reduce the number of times you have to type in the long password - and hence make the full password stronger.  My password manager does that.  But... Apple does not. At least not for 48 hours or next power-cycle.



So, we will give device passwords a pass. Ideally, you have them physically secure, and you aren't rlogin-ing in to them.  Ideally, there is a different, stronger, password for remote access...



Moving on to (3), the Apple iCloud password.  You have to type it in a lot, not only during install, but also when installing apps.  Plus Apple, in their infinite wisdom, has made it difficult to use password managers with it.  (Note: I don't use Apple Keychain much.)



So, the Apple iCloud password is arguably comparable in importance to your iPhone password, and more vulnerable. More vulnerable, because the iCloud password can be entered by an attacker into Apple's webpages, i.e. it can be entered remotely.  Only arguably comparable in importance, because while the  iCloud password controls a lot of stuff, your device password probably controls access to some of your 2-factor authentication.



Those are probably my most important passwords:

(1) password manager

(2) device

(3) iCloud.



Interestingly, my Google password is not in this list in category (3), even when I use an Android device. Google seems to be friendlier to password managers than Apple is, probably because of its web.site DNA.



My Microsoft password may be in category (3).  I don't use it enough to be sure, although from one situation in a Microsoft store I think they have made some of their services uncooperative to password managers, and hence encouraging of weak passwords.



Finally, (4) my company password.  Often entered, often uncooperative with password managers, e.g. in Microsoft Windows login, Exchange, VPN, Perforce. Often enough that I have simply had to memorize it - and it is therefore weaker than I would like.  It doesn't piss me off as much, because it's the company's secrets that are at risk, not so much my own.  I have encouraged IT to use a  better password system, friendlier to password managers -and IT's response has been to require that the password be changed more often.  Which makes it harder to remember.  Which encourages me to weaken the password.



---



Now, having listed these, I have probably opened myself up to attack.  Blargh.



---



Backing up: it is harder to enter a good password on a mobile device touch keyboard than on a physical keyboard.



Key clicks are bad. Different keyclicks for different keys are really bad, even if just "clack" for shift key and "click" for all other keys.



But even without keyclicks, shift keys make it harder to enter good passwords.



Ideally, high entropy passwords would be a random combination of A-Za-z0-9~`!@#$%^&*()_-+={}[]||"'<>,?/:;.  (I don't think many systems allow control characters in passwords. Non-English unicode? Notice that your iPhone keyboard has characters that are a pain to type on a USASCII keyboard? How about emoji?)



Uniformly weighted.



(With easy to attack patterns pulled out - e.g. all 0s can be produced by a random password generator. But I still would not use it as a password.)



Roughly speaking, there are circa 4*26 characters for passwords. If you have a lowercase letter, there's a 75% chance that you will have to type a shift key. And so on.  Roughly speaking, you would have to hit 1.75 keys for every random character in your password - and that does not even include the times you have to hit number shift then symbol shift.



I posit that part of the difficulty of typing a password is the number of keys you have to hit.  The raw physical activity.  Not just the memorization.  So if truly random passwords require 1.75 keys per character, I posit that users may prefer to use passwords that are 4/7s the length of what they might use on a keyboard that required fewer shifts.  (Note: I think physical keyboards are less onerous in this regards than thumb keyboards.)



E.g. instead of 28 characters, Apple's crippled keyboard might lead to users creating passwords that are only 16 characters long.   21->12.  14-> no, that's horrible!!!



Do the math: the longer password from the smaller alphabet can be a win.  But 1.75x is probably an overestimate for the increased difficulty.



I posit that, for the passwords you have to enter on Apple iPhone keyboard, you might be wise to reduce the frequency of shifts.  Not eliminate them.  And not fixed length groups of the same shift.  But perhaps pull from a distribution that does not create quite so many shifts.  Where the average touches per character of the password is more than 1, but less than 1.75.



Perhaps random password generators should take this into account: the typing efficiency of the password. On what is probably the worst keyboard for typing, the Apple iPhone.



===



Of course, the real fix to the problem of passwords is to get rid of most passwords.



In the 1990s I wrote up an invention disclosure for my employer, Intel, for what I called a "security amulet".  I don't think Intel did anything with it.



The basic idea was to have something you wear. Like an amulet around your neck, or a watch. Possibly surgically implanted. Physical security being part of it.



The security amulet would be net.connected.  Your amulet's address would be registered as part of your identity.  When you try to log in to a website, the website contacts your security amulet.  The amulet asks you "Do you want to log in to your bank?"  You confirm, or deny.



The amulet could store passwords. Or a time varying code like Google Authenticator.  Better yet if it does challenge response, public/private key style.



The thing you are trying to log into could connect over the net.  Or you could be disconnected from the net, and logging into a device locally, without going through the net. E.g. bluetooth - back in the day, I liked body area networks, e.g. skin conductivity, between amulet and keyboard.  Or you could do both: triangle device<--internet-->website<--internet-->amulet->localnet<-->device.  Verify not just that somebody in possession of your amulet approves, but that the amulet is also physically close to the device where the action is taking place.  (Unless spoofed, of course. Time delay?)



You authenticate to your amulet... howsoever you want.  Some amulets might require you to type a password in once a day.  Some might use biometrics like fingerprint.  Some might monitor your pulse, to detect when you have taken the amulet off.  Some might check DNA.  Some might do nothing. The point is, once the protocols between device, service, and amulet are established, then innovation can happen between the user and the amulet.  Whereas nowadays we are all constrained by what Google, etc, accept.  The largely time based authenticator apps are better than passwords.  Watch authenticator apps are better still.  But still not there.


Back in the 1990s too much infrastructure was needed.  There was no standard way to talk to a security amulet. Mobile was still analog. The Bluetooth SIG started in 1998.  People thought that I was crazy for wanting public key in a watch-like device.



But all of these pieces are in place nowadays.  The missing piece is that Google Authenticator still expects you to type in a code. But we now have push authentication, which scares me because the user interaction is so trivial, and hence insecure.  Especially on a phone, which can be easily misplaced, and easily unlocked given fingerprints.



What I want today: push authentication to my watch.  And time based on my watch. Etc.






















Your most important passwords a probabl your weakest passwords

Have you ever noticed that your most important passwords are your weakest passwords?



Most of my passwords are random 20-24-32 Letter+Number*Symbol=Passwords. Stored in a password manager, because I can't remember them. Several hundred, different for each site. For that matter the account names and email are mostly different. Automatically entered into websites when I say okay. I am less happy when I have to cut and paste passwords, because clipboards can be a security hole. Anyway, not only do I not need to remember these passwords, but I don't have to type them in.



So, consider the passwords left over.



First, (1)  the password for the password manager itself. My most important password. Because I have to remember it, and type it on at least 2 different keyboards - phone, laptop - it probably has less entropy than most of the passwords in my password manager.



Worse: it is long enough and hard enough to type that I have more than once hit "show me my password", when repeated tries fail.  So any camera looking over my shoulder may have captured it from the screen.  Like a security camera in an airport.



Of course, even without "show me my password", a camera may see your typing.



Change it frequently, but then entry errors rise.



When I have trouble entering my password usually arises on my iPhone keyboard. Good passwords are easier to type on a full keyboard.  Not only are mobile phone keyboards, and in particular Apple's iPhone keyboards, cramped and likely to produce wrong key errors - but you also have to shift to get numbers and symbols. Sometimes multiple shifts.



Oh, and you probably should have audible keyclicks turned off. Have you noticed that Apple provides a different click for the shift key that changes between lowercase, uppercase, numbers, and symbols?  I am sure anyone with a microphone can record that and greatly reduce the password search space.  Even without different clicks, inter-key delay provides a lot of attack info.



Recently I have had to do a factory reset and reinstall from scratch on my Apple iPhone 3 times within the same month.  (I think/hope the iPhone flash storage has errors - or else the iOS apps are full of bugs that may become security holes.)



Doing this has driven home how many times you have to type in (2) the password for the device itself, and (3) Apple's iCloud password.



Now, device passwords, such as for your phone or tablet or laptop, of necessity need to be typed in a lot. One of the best things about fingerprints is that, ideally, you can use the fingerprint to reduce the number of times you have to type in the long password - and hence make the full password stronger.  My password manager does that.  But... Apple does not. At least not for 48 hours or next power-cycle.



So, we will give device passwords a pass. Ideally, you have them physically secure, and you aren't rlogin-ing in to them.  Ideally, there is a different, stronger, password for remote access...



Moving on to (3), the Apple iCloud password.  You have to type it in a lot, not only during install, but also when installing apps.  Plus Apple, in their infinite wisdom, has made it difficult to use password managers with it.  (Note: I don't use Apple Keychain much.)



So, the Apple iCloud password is arguably comparable in importance to your iPhone password, and more vulnerable. More vulnerable, because the iCloud password can be entered by an attacker into Apple's webpages, i.e. it can be entered remotely.  Only arguably comparable in importance, because while the  iCloud password controls a lot of stuff, your device password probably controls access to some of your 2-factor authentication.



Those are probably my most important passwords:

(1) password manager

(2) device

(3) iCloud.



Interestingly, my Google password is not in this list in category (3), even when I use an Android device. Google seems to be friendlier to password managers than Apple is, probably because of its web.site DNA.



My Microsoft password may be in category (3).  I don't use it enough to be sure, although from one situation in a Microsoft store I think they have made some of their services uncooperative to password managers, and hence encouraging of weak passwords.



Finally, (4) my company password.  Often entered, often uncooperative with password managers, e.g. in Microsoft Windows login, Exchange, VPN, Perforce. Often enough that I have simply had to memorize it - and it is therefore weaker than I would like.  It doesn't piss me off as much, because it's the company's secrets that are at risk, not so much my own.  I have encouraged IT to use a  better password system, friendlier to password managers -and IT's response has been to require that the password be changed more often.  Which makes it harder to remember.  Which encourages me to weaken the password.



---



Now, having listed these, I have probably opened myself up to attack.  Blargh.



---



Backing up: it is harder to enter a good password on a mobile device touch keyboard than on a physical keyboard.



Key clicks are bad. Different keyclicks for different keys are really bad, even if just "clack" for shift key and "click" for all other keys.



But even without keyclicks, shift keys make it harder to enter good passwords.



Ideally, high entropy passwords would be a random combination of A-Za-z0-9~`!@#$%^&*()_-+={}[]||"'<>,?/:;.  (I don't think many systems allow control characters in passwords. Non-English unicode? Notice that your iPhone keyboard has characters that are a pain to type on a USASCII keyboard? How about emoji?)



Uniformly weighted.



(With easy to attack patterns pulled out - e.g. all 0s can be produced by a random password generator. But I still would not use it as a password.)



Roughly speaking, there are circa 4*26 characters for passwords. If you have a lowercase letter, there's a 75% chance that you will have to type a shift key. And so on.  Roughly speaking, you would have to hit 1.75 keys for every random character in your password - and that does not even include the times you have to hit number shift then symbol shift.



I posit that part of the difficulty of typing a password is the number of keys you have to hit.  The raw physical activity.  Not just the memorization.  So if truly random passwords require 1.75 keys per character, I posit that users may prefer to use passwords that are 4/7s the length of what they might use on a keyboard that required fewer shifts.  (Note: I think physical keyboards are less onerous in this regards than thumb keyboards.)



E.g. instead of 28 characters, Apple's crippled keyboard might lead to users creating passwords that are only 16 characters long.   21->12.  14-> no, that's horrible!!!



Do the math: the longer password from the smaller alphabet can be a win.  But 1.75x is probably an overestimate for the increased difficulty.



I posit that, for the passwords you have to enter on Apple iPhone keyboard, you might be wise to reduce the frequency of shifts.  Not eliminate them.  And not fixed length groups of the same shift.  But perhaps pull from a distribution that does not create quite so many shifts.  Where the average touches per character of the password is more than 1, but less than 1.75.



Perhaps random password generators should take this into account: the typing efficiency of the password. On what is probably the worst keyboard for typing, the Apple iPhone.



===



Of course, the real fix to the problem of passwords is to get rid of most passwords.



In the 1990s I wrote up an invention disclosure for my employer, Intel, for what I called a "security amulet".  I don't think Intel did anything with it.



The basic idea was to have something you wear. Like an amulet around your neck, or a watch. Possibly surgically implanted. Physical security being part of it.



The security amulet would be net.connected.  Your amulet's address would be registered as part of your identity.  When you try to log in to a website, the website contacts your security amulet.  The amulet asks you "Do you want to log in to your bank?"  You confirm, or deny.



The amulet could store passwords. Or a time varying code like Google Authenticator.  Better yet if it does challenge response, public/private key style.



The thing you are trying to log into could connect over the net.  Or you could be disconnected from the net, and logging into a device locally, without going through the net. E.g. bluetooth - back in the day, I liked body area networks, e.g. skin conductivity, between amulet and keyboard.  Or you could do both: triangle device<--internet-->website<--internet-->amulet->localnet<-->device.  Verify not just that somebody in possession of your amulet approves, but that the amulet is also physically close to the device where the action is taking place.  (Unless spoofed, of course. Time delay?)



You authenticate to your amulet... howsoever you want.  Some amulets might require you to type a password in once a day.  Some might use biometrics like fingerprint.  Some might monitor your pulse, to detect when you have taken the amulet off.  Some might check DNA.  Some might do nothing. The point is, once the protocols between device, service, and amulet are established, then innovation can happen between the user and the amulet.  Whereas nowadays we are all constrained by what Google, etc, accept.  The largely time based authenticator apps are better than passwords.  Watch authenticator apps are better still.  But still not there.


Back in the 1990s too much infrastructure was needed.  There was no standard way to talk to a security amulet. Mobile was still analog. The Bluetooth SIG started in 1998.  People thought that I was crazy for wanting public key in a watch-like device.



But all of these pieces are in place nowadays.  The missing piece is that Google Authenticator still expects you to type in a code. But we now have push authentication, which scares me because the user interaction is so trivial, and hence insecure.  Especially on a phone, which can be easily misplaced, and easily unlocked given fingerprints.



What I want today: push authentication to my watch.  And time based on my watch. Etc.






















Friday, October 28, 2016

Bash trap DEBUG does not work inside shell functions - not even to print

Bash Reference Manual:
trap
If a sigspec is DEBUG, the command arg is executed before every simple command, for command, case command, select command, every arithmetic for command, and before the first command executes in a shell function. Refer to the description of the extdebug option to the shopt builtin (see The Shopt Builtin) for details of its effect on the DEBUG trap.


'via Blog this'
This bit me today:



It seems that



  • not only does the bash DEBUG trap not run for commands inside shell functions, but only once at the start
    • which is not unreasonable as a default
    • especially if shopt extdebug allowed you to "trap DEBUG into" shell functions (which I have so far not been able to make work)
  • but "trap ... DEBUG" is actually disabled inside shell functions
    • which means that you cannot have a shell function that formats the current trap status nicely
    • or which tries to add a "trap ... DEBUG" handler to its caller


Unless I can get shopt extdebug to work as advertised - well, at least, as I tyhinik it is advertised - there is a loss of abstraction.



Kluge: pass in the old trap handler setup, compute new, apply outside function.



:-(





A shell session.





    Mac: trap

    trap -- 'shell_session_update' EXIT



It looks like Apple sets up a trap handler by default.



    Mac: trap 'echo DEBUG' DEBUG

    DEBUG



Setting up a trivial (but annoying) DEBUG trap handler.

Run once before any command is run.



    Mac:

    DEBUG



Or even when ENTER is pressed to get a new prompt





    Mac: echo xx

    DEBUG

    xx

    DEBUG



Run twice as set up above, once for the command,

once for the exit handler





Now trying to run trap in a function



    Mac: trap

    DEBUG

    trap -- 'shell_session_update' EXIT

    trap -- 'echo DEBUG' DEBUG

    DEBUG



    Mac: foo() {

    > trap

    > }

    DEBUG



    Mac: foo

    DEBUG

    trap -- 'shell_session_update' EXIT

    DEBUG



The shell function can execute the trap builtin

but the trap DEBUG handler was disabled












Tuesday, October 25, 2016

Pebble, dynamic app swapping

Pebble | Updated Software for Classic Pebbles: "No more 8 app limit"
'via Blog this'
I have the original Pebble.

Originally, this Pebble classic had an 8-app limit.  You could not have more than 8-apps.  This was limiting, but I could live with it.  Although I have played with many apps, I only really use two apps regularly:

(1) the Misfit step counter and sleep tracker - which is supposed to run in the background

(2) the "smart" Gentle Alarm app - which has made waking up almost pleasabnt, because it finds a good time in my sleep cycle to wake me up.

These fit comfortably in the original 8-app limit.


The Pebble SW upgrade that removed the 8-app limit at first seemed not to affect these. But recently...  :-(
  • Repeatedly, including this morning, I switched to my supposedly-always-running Misfit step counter - and I got the progress bar that indicates that the app is not resident on the watch, and is being swapped back in from my phone.
  • At least this morning I had my phone with me.  Unfortunately, I had already walked quite distance, so missed steps 
  • Other times my phone not with me: I often do NOT carry my phone with me on my morning dog walks. So the step counter app hung.  (I live in a canyon - no signal, so it is useless as a phone on my walks. I only carry it occasionally for a podcast player) 
  • One morning I woke up late - the Gentle Alarm app on my Pebble watch had not gone off - and I saw the progress bar that indicates that the app is not resident on the watch, and is trying to swap back in. But I had forgotten to charge my phone, so the watch app was hung trying to swap back in.
This is very unfortunate.  The only two apps that I really want on my watch depend on being present all the time.  There appears to be no way to guarantee that they will not be swapped out.

I have deleted all unnecessary apps.  Factory reset.  But I still seem to get this swapping in  and out.  (I conjecture that Pebble's default apps may swap them out, e.g. for notifications.)

This may be my last straw for the Pebble.  I have been considering buying a FitBit Blaze, even though it lacks smart alarms.  It is sad that software upgrades kill my usage model.

Rant:

Far too many folks assume that everyone always carries their phone with them. False!  Certainly false in the fitness tracker and alarm space.

Apple iPhone and Google Android apps have similarly started to be swapped or paged in from the cloud.   Unfortunately, when you live in a place that does not always have connectivity, sometimes the apps do not work, even though they do not require connectivity except to page.   Even when connected, the apps are slower.

Thursday, September 29, 2016

Exchange Requires iPhone to Auto-lock

I just wasted 20 minutes trying to prevent my iPad from locking so quickly.



Since I was using my iPad for Quadro, as a UIX user interface extension, with macro keys, it sucked to have to unlock it so frequently.



Since I hardly ever use my iPad for Exchange, I completely removed the Exchange accounts.



I should try to see if I can set up conditional autolock - autolock after 15 minutes when linked in via USB to Quadro on my MacBook, else autolock after 2 minutes, etc.



This is one place where face recognition might be good: don't autolock if my face has been continuously in front of iPad...



(I don't want to login using just my face.)







Exchange Requires iPhone to Auto-lock: "Exchange Requires iPhone to Auto-lock"



'via Blog this'

Monday, September 26, 2016

MODULES FOR XUNIT TESTING IN PERL

Test::Class : "MODULES FOR XUNIT TESTING IN PERL"



'via Blog this'



Not a bad summary:



Test::Unit is a port of JUnit into Perl.  Familiar to xUnit users.



Test::Class

Much like xUnit.  xUnit inspired. Unfamiliar names muck up porting, but can live with that.

Plays well with traditional Perl test tools like TAP and Test::Builder.

Somewhat object oriented.  But

 Test::Class does not provide its own test functions, but uses those provided by Test::More and friends 
which are free functions, so somewhat annoying to extend (e.g. to report error location accurately, when you build meta-tests that call multiple asserts internally). But you can access the underlying Test::Builder routines.

Uses :Test attribute so that introspection can find test functions to rub, including setup/teardown.

Pleasant - many folks have had to add such "keep running" behaviour to xUnit.

Unlike JUnit the test functions supplied by Test::More et al do not throw exceptions on failure. They just report the failure to STDOUT where it is collected by Test::Harness. This means that where you have
sub foo : Test(2) {
      ok($foo->method1);
      ok($foo->method2);
      ok($foo->method3) or die "method3 test failure";
      ok($foo->method4);
  }

The second test will run if the first one fails But the third will stop the fourth from running.
Test::Unit

Test::Unit is a port of JUnit http://www.junit.org/ into perl. If you have used JUnit then the Test::Unit framework should be very familiar.

It is class based so you can easily reuse your test classes and extend by subclassing. You get a nice flexible framework you can tweak to your heart's content. If you can run Tk you also get a graphical test runner. However, Test::Unit is not based on Test::Builder. You cannot easily move Test::Builder based test functions into Test::Unit based classes. You have to learn another test assertion API.

Test::Unit implements it's own testing framework separate from Test::Harness. You can retrofit *.t scripts as unit tests, and output test results in the format that Test::Harness expects, but things like todo tests and skipping tests are not supported.


But... the Test::Case author does not say that Test::Unit is mostly abandoned as odf 2016, possibly since 2011 or before.  

Test::SimpleUnit

A very simple unit testing framework. If you are looking for a lightweight single module solution this might be for you. The advantage of Test::SimpleUnit is that it is simple! Just one module with a smallish API to learn. Of course this is also the disadvantage.

It's not class based so you cannot create testing classes to reuse and extend. It doesn't use Test::Builder so it's difficult to extend or integrate with other testing modules. If you are already familiar with Test::BuilderTest::More and friends you will have to learn a new test assertion API. It does not support todo tests.

MODULES FOR XUNIT TESTING IN PERL

Test::Class : "MODULES FOR XUNIT TESTING IN PERL"



'via Blog this'



Not a bad summary:



Test::Unit is a port of JUnit into Perl.  Familiar to xUnit users.



Test::Class

Much like xUnit.  xUnit inspired. Unfamiliar names muck up porting, but can live with that.

Plays well with traditional Perl test tools like TAP and Test::Builder.

Somewhat object oriented.  But

 Test::Class does not provide its own test functions, but uses those provided by Test::More and friends 
which are free functions, so somewhat annoying to extend (e.g. to report error location accurately, when you build meta-tests that call multiple asserts internally). But you can access the underlying Test::Builder routines.

Uses :Test attribute so that introspection can find test functions to rub, including setup/teardown.

Pleasant - many folks have had to add such "keep running" behaviour to xUnit.

Unlike JUnit the test functions supplied by Test::More et al do not throw exceptions on failure. They just report the failure to STDOUT where it is collected by Test::Harness. This means that where you have
sub foo : Test(2) {
      ok($foo->method1);
      ok($foo->method2);
      ok($foo->method3) or die "method3 test failure";
      ok($foo->method4);
  }

The second test will run if the first one fails But the third will stop the fourth from running.
Test::Unit

Test::Unit is a port of JUnit http://www.junit.org/ into perl. If you have used JUnit then the Test::Unit framework should be very familiar.

It is class based so you can easily reuse your test classes and extend by subclassing. You get a nice flexible framework you can tweak to your heart's content. If you can run Tk you also get a graphical test runner. However, Test::Unit is not based on Test::Builder. You cannot easily move Test::Builder based test functions into Test::Unit based classes. You have to learn another test assertion API.

Test::Unit implements it's own testing framework separate from Test::Harness. You can retrofit *.t scripts as unit tests, and output test results in the format that Test::Harness expects, but things like todo tests and skipping tests are not supported.


But... the Test::Case author does not say that Test::Unit is mostly abandoned as odf 2016, possibly since 2011 or before.  

Test::SimpleUnit

A very simple unit testing framework. If you are looking for a lightweight single module solution this might be for you. The advantage of Test::SimpleUnit is that it is simple! Just one module with a smallish API to learn. Of course this is also the disadvantage.

It's not class based so you cannot create testing classes to reuse and extend. It doesn't use Test::Builder so it's difficult to extend or integrate with other testing modules. If you are already familiar with Test::BuilderTest::More and friends you will have to learn a new test assertion API. It does not support todo tests.